Brewery Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does modelling the batch instead of the transfer sink so many brewery builds?

Nearly every brewery software project starts with a whiteboard drawing of a batch: recipe in, fermentation, packaging out, a parent with children. It is intuitive, it matches how brewers talk, and it breaks the first time a real cellar does anything interesting. Blend two tanks and the tree has two parents. Split a brite across two package formats and it has two children with different tax treatments. Transfer in bond from your second facility and the batch has an origin outside the tree entirely. Pull from a foeder that has been topped up over eighteen months and the lineage is a proportion, not a parent.

What makes this specific to brewing rather than to manufacturing generally is that the tax event and the physical event are different things. Beer removed for consumption or sale, beer removed without tax for export or research, loss in transfer, beer returned to brewery: those are categories that attach to a movement of liquid, not to a batch. A schema built around batches has to reconstruct them, which is exactly why the reconstruction ends up in Excel and stays there.

The fix is to make the immutable transfer the base object and let batches be a view over it. Every liquid movement records volume, source vessel, destination vessel, timestamp, operator and a tax determination flag. Blends and foeder programmes get a proportional lineage graph, so a single package run attributes back across five source vessels with correct volumes. Transfers in bond between your own facilities generate matched paired records on both sides automatically. Ask any developer to model a blend on a whiteboard in the first meeting: three foeders, two stainless tanks, one package run, correct attribution, and a report line that ties. A team that draws a parent and child tree will be visibly wrong inside two minutes, and that one question separates people who have built for breweries from people who have built inventory apps.

What goes wrong when you migrate batch history and recipes off Ekos?

Migration is where brewery builds lose four to six weeks that nobody planned for, and the cause is almost never the export mechanism. Ekos data comes out through export and its interface, and getting the bytes is the easy part. The trouble starts when you look at what is in them.

Recipes have forked. The version in the system is not the version the head brewer actually uses, because he adjusted the dry hop schedule two seasons ago and updated the card on the wall rather than the software. Vessel names have been reused: the tank called FV7 today is a different vessel from the FV7 that existed before the 2022 expansion, and historic batches point at a name rather than an asset. SKU catalogues carry retired formats and seasonal variants that were entered three different ways. Gyle numbers restart annually in some breweries and run continuously in others, and both conventions may appear in one data set after an acquisition.

Then there is the honest problem: your historic yields were entered as reconstructions rather than records, so importing them produces a trend line that looks authoritative and describes a brewery that never existed.

The fix is to import historic batches as read only records, clearly labelled as legacy, so yield trends survive the move without pretending to a precision they never had. Map vessels to assets with effective dates rather than to names. Reconcile the SKU catalogue with your sales team before import, not after. Anything that fails to map goes to an exception list a human works through, never to a default. And expect to find data quality problems in the old system that you will have to make decisions about, which is a reason to have your controller and head brewer in the migration sessions rather than only your project sponsor.

Why do distributor EDI and taproom POS integrations break after launch?

Distributor integration is the single most reliable source of post launch surprise in this category, and the reason is structural rather than technical. Every distributor's 852 and 867 implementation is effectively its own dialect. Segment usage differs, product identifiers differ, and the same document from two wholesalers requires two mappings. So a build that integrated three distributors successfully does not have a distributor integration, it has three, and the fourth is a new project.

Depletion reporting is worse, because much of it never becomes a document at all. It arrives as a PDF, as a spreadsheet with merged header cells, or as a portal export whose column order changes when the distributor upgrades their system. Nothing errors when that happens. The file imports, the columns are misaligned, and your depletion numbers are quietly wrong for a month.

Taproom point of sale integration with Arryved or Toast is usually smoother, since both offer workable interfaces, but it breaks in its own way: a new modifier or a comped item category appears at the bar, nothing maps it, and taproom volume stops reconciling against packaging.

The fixes are the same shape as anywhere else and they need to be in the plan. Version your mappings per trading partner. Validate on import against expected totals and known SKUs, and reject rather than accept a file whose shape has changed. Monitor for absence of expected files per distributor per period, because a wholesaler who stops sending is invisible until quarter end. Keep a document extraction pipeline for the PDF and spreadsheet reports, flagging ambiguous rows for a human and posting the rest, which at breweries covering six or seven states has given our clients back 12 to 20 hours a month. And price each additional distributor as its own line rather than as a configuration change.

What happens when TTB and state excise reporting is not properly covered?

The Brewer's Report of Operations, TTB Form 5130.9, and the excise tax return that goes with it are legally binding documents with a signature on them. In most breweries they are produced by exporting from the production system, adjusting in Excel for the things the export got wrong, and having the controller or head brewer sign. That means the workbook is the real system of record and the production software is a data source, which is backwards, and it concentrates a federal filing on one person's understanding of one spreadsheet.

Builds go wrong here in two ways. The first is treating the report as a rendering problem rather than a data model problem, which puts you straight back to Excel the moment a blend or a transfer in bond appears. The second is treating state excise as a variant of federal. It is not. Each state has its own rules, categories and filing formats, and a brewery selling into eleven states has eleven separate pieces of work, not one report with a state filter.

The fix begins with the transfer ledger described earlier, because once every movement carries a tax determination flag the report becomes a query rather than an assembly. Beyond that, three things matter. Encode each state's rules once, explicitly, with the state named on the rule so an update is a contained change. Build the audit trail from the first commit rather than adding it when somebody asks, so that a question about where 14.2 barrels went in March is answered by running a query and handing over a trail. And have your controller validate the report logic against real historical filings before go live, comparing period by period against what you actually submitted. If the new system cannot reproduce last year's filings, it is not ready to produce this year's.

Should you build custom or configure what you already own?

Some breweries should not build, and the line is reasonably clear. Under roughly 6,000 barrels a year from one location, with most volume through your own taproom and fewer than about twenty wholesale accounts, Ekos or Beer30 is the right answer and a custom build is a vanity project. Those products have absorbed a decade of brewery specific edge cases you would be paying to rediscover, and the subscription is not what hurts your profit and loss. Buy it, use it properly, and put the capital into stainless.

Even at larger scale, configure before you build. Most breweries have never set up their vessel list to match the actual plant, never cleaned the SKU catalogue, never used the reporting they already pay for, and never asked whether their existing keg module can be made to work with better scanning discipline. It is common to find that a meaningful share of the daily friction is unconfigured rather than unbuildable, and that costs a few weeks of an operations lead rather than six figures.

The signals that configuration has run out are specific. You have a full time or half time person whose actual job is moving data between systems. Your Brewer's Report of Operations is assembled in Excel and one person understands the workbook. Your keg float with distributors is a number you argue about rather than report. You run two or more production sites. You have a barrel or blending programme your current system cannot represent, so it lives in a parallel spreadsheet. Or you are about to sign a distributor that requires EDI and your stack has no answer. Any two of those together and the arithmetic has usually already turned, you simply have not priced the reconciliation labour, which at the 25,000 barrel breweries we have scoped runs 25 to 40 hours a month across production, finance and sales roles.

How do hidden costs get into the quote?

Brewery quotes go wrong in a pattern that is easy to spot once you know it.

The first hidden cost is distributor EDI priced as one item. It is one item per trading partner, and three or more connections push a project toward the upper half of the $150k to $400k full platform band in our delivery experience.

The second is offline first mobile. Coolers, dock areas and tank farms have no signal, and a scanner application that assumes connectivity gets abandoned in month three. Offline first costs more than a plain web application because conflict resolution has to be designed, including what happens when two people scan the same keg on two devices, and it needs testing in a real cooler rather than in an office with the network switched off.

The third is multi state excise, which is separate work per state rather than a configuration option.

The fourth is accounting integration where cost of goods has to roll correctly per batch rather than per invoice. Pushing invoices to QuickBooks is easy. Rolling recipe level cost into a per batch margin that your controller trusts is not.

The fifth is barrel aged and blending programmes, because proportional lineage across foeders is genuinely difficult and the reporting has to survive an audit rather than merely look right.

The sixth is the one nobody lists: cellar crew time during design. If the people who work off the whiteboard are not in the room, you will build something the office likes and the cellar ignores. Ask bidders to price distributors, states, mobile scanning and accounting separately so you can compare on the same list.

What separates a brewery build that works from one that fails?

The builds that work are recognisable before a line of code is written. Ask the team to model a blend, and watch whether they reach for a transfer ledger or a batch tree. Ask what happens when the scanner has no signal, and listen for a local queue with a defined conflict resolution rule rather than a suggestion that the user retries. Ask about state excise experience by name rather than in general.

They ship one thing properly rather than everything partially. The right first release is whichever module is bleeding most: the keg ledger with offline scanning and distributor deposit reconciliation, or the transfer ledger with a compliant report. In our delivery experience a focused first release runs $60k to $130k and ships in 12 to 16 weeks, reading from your existing system by export or interface while the rest of the stack stays put. Breweries that insist on a full platform before anything goes live spend a year building and a year explaining the delay.

They design keg tracking as an event ledger rather than a count, because that is what produces aged float by distributor, dwell time per account and a quarterly deposit reconciliation packet you can send to a distributor's accounts receivable team as a document rather than a request. Breweries we have built this for typically recover the keg module build cost from float recovery and loss reduction inside 18 months.

They involve the cellar crew in design and the controller in report validation, because those two groups decide whether the system is used and whether it is trusted.

And they settle ownership in writing before the first invoice. You should get the repository, the infrastructure accounts and the ability to hire a different firm next year without a negotiation. If ownership is conditional on an ongoing retainer, that is a lock in arrangement rather than a build.