Brewery Management Software: Why Your Kegs, Tanks, and TTB Filings Stop Agreeing at Scale

Why brewery management software makes or breaks a multi-site production brewery

Walk into most 25,000 barrel breweries at 6am and you find the same setup. A production manager with a clipboard. A whiteboard at the tank farm with tank numbers in dry-erase marker. A laptop open to Ekos that nobody has touched since Thursday. The cellar crew works off the whiteboard because it is right there and it is always current. Ekos gets updated later, in a batch, by whoever loses that argument. By the time the numbers land in the system they are a reconstruction rather than a record.

The stack is predictable: Ekos or Beer30 for production and inventory, QuickBooks or Xero for accounting, Arryved or Toast for the taproom, a shared Google Sheet for keg accounts, VIP or Lilypad for distributor depletion data if you are big enough to pay for it, and Fintech for the ACH side. Neither Ekos nor Beer30 publishes a rate card, and the subscription is not what hurts. What hurts is that none of these systems agree with each other. The production manager exports a CSV from Ekos, the controller pastes it into a workbook handed down through three finance hires, and someone spends the last four days of every month making the TTB Brewer's Report of Operations match what the tanks actually did. At the 25,000 barrel breweries we have scoped, that reconciliation burns 25 to 40 hours a month across production, finance, and sales roles. A full week of somebody's salary, spent making numbers agree that should never have disagreed.

Here is the version that costs real money. A 30 barrel batch of your flagship goes into FV4. Somewhere between fermentation and packaging you lose 1.8 barrels to trub and transfer. The cellar log says 30 in. The packaging count says 28.2 out. Ekos wants a yield number, so someone types 28.2 and the variance lands in a field nobody reports on. Do that 200 times a year and 360 barrels of unexplained shrink have left the building with no data trail telling you whether it was a bad hose connection on FV4, one brewer's transfer technique, or a dry-hop recipe that is thirstier than the recipe card claims. Price that against your own wholesale rate. It is a number you would fire someone over if it landed on a single invoice. Spread across 200 batches, nobody sees it at all.

Problem: kegs are your biggest asset and your worst-tracked one

A 20,000 barrel brewery running half-barrel and sixtel fleets owns thousands of kegs. Price the fleet off your last keg purchase order and it is comfortably a seven-figure asset that lives on a spreadsheet. Kegs go out on a delivery manifest, arrive at a distributor DC, get split to accounts, come back eventually, or do not. Deposit reconciliation with a distributor happens quarterly, if that, and it is a negotiation rather than an audit because neither side has clean data. Every brewery we have worked with quotes an annual keg loss percentage from memory and cannot substantiate it, and every one of them treats it as weather.

Ekos and Beer30 both have keg modules. They track counts and scan barcodes. What they cannot do is model your actual keg economics: a keg sitting at a chain account 90 days past freshness, a distributor whose float has quietly grown by 400 kegs over two years, a self-distribution route where your own driver picks up empties that never get scanned back in because the scanner app times out in a walk-in cooler with no signal. The incumbent tools assume connectivity, assume one flow direction, and treat every keg as fungible. Your CFO does not.

A custom build makes the keg an entity with a full event ledger instead of a count. Every keg carries a lifetime record: fill date, batch ID, gyle number, seam date, destination, days on site, cleaning cycles, and a deposit ledger tied to a specific distributor contract with its own float agreement. Scanning runs offline-first on a rugged handheld or a phone, queues locally, and syncs when it hits WiFi at the dock, because the cooler has no bars and pretending otherwise is why the incumbent scanner apps get abandoned in month three. Then you build the report that moves money: aged keg float by distributor, per-account dwell time, and a quarterly deposit reconciliation packet you email to the distributor's AR team as a defensible 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.

Problem: TTB reporting is a manual reconstruction, and it is legally binding

The Brewer's Report of Operations (TTB F 5130.9) is due monthly or quarterly, and the excise tax return (5000.24) goes with it. Most breweries produce it by exporting from Ekos, adjusting in Excel for the things Ekos got wrong, and having the controller or head brewer sign it. Every line has to tie to production records a TTB auditor can walk. In practice the workbook is the real system of record and the ERP (Enterprise Resource Planning) is a data source. That is backwards, and it is a compliance exposure: your signed federal filing is derived from a spreadsheet one person understands.

The incumbent tools do generate a BROP. The problem is what happens to it. Beer removed for consumption or sale, beer removed without tax for export or research, loss in transfer, beer returned to brewery: those categories map to physical events in your cellar that the off-the-shelf schema flattens. Barrel-aged and blended beer breaks it entirely. A blend pulled from three foeders and two stainless tanks, some of it transferred in bond from your second facility, does not survive a system that models a batch as a linear parent-child tree. So it gets handled manually, in Excel, forever.

A custom build models the transfer rather than the batch. Every liquid movement is an immutable event with volume, source vessel, destination vessel, timestamp, operator, and a tax-determination flag. The BROP becomes a query over that ledger instead of a report someone assembles. Blends and foeder programs get a proportional lineage graph, so a single package run attributes back to five source vessels with correct volumes. Transfers in bond between your facilities generate matched paired records on both sides automatically. When an auditor asks where 14.2 barrels went in March, you run a query and hand over a trail. If you run a taproom-plus-distribution model with state excise stacked on federal, you encode each state's rules once and stop maintaining eleven spreadsheets.

AI does one unglamorous job here well: document extraction. Distributor depletion reports arrive as PDFs, as XLS files with merged header cells, and as portal exports that change format when the distributor upgrades their system. Rather than paying a sales ops coordinator to normalize them, an extraction pipeline reads each file, maps columns to your SKU and account model, flags anything ambiguous for a human, and posts the rest. At breweries covering six or seven states, we have seen that alone give back 12 to 20 hours a month.

Problem: your production schedule is a whiteboard and your tank farm is the constraint

Tank turns are the whole game. A 40,000 barrel brewery with 18 fermenters and 4 brites lives or dies on whether FV7 frees up on Tuesday or Thursday. The head brewer holds the schedule in his head and on the whiteboard. Sales sells a limited release for a date that assumes a tank that is not actually free. The packaging line gets a 4am change because a diacetyl rest ran long and nobody upstream knew until the crew showed up.

Ekos has a scheduling calendar. It is a calendar. It does not know your Kolsch needs 21 days and your hazy needs 14 with two dry hop additions, that the CIP crew is two people, that the canning line runs at one rate on 16oz and a different rate on 12oz, or that transferring FV7 to BBT2 blocks BBT2 for 6 days. It cannot tell you the cost of saying yes to the sales team's new SKU, because your vessel graph is unique to your building and no vendor models it.

A custom build encodes a constraint model of your actual plant: vessels with capacities and cleaning states, recipes with time-in-tank profiles and hop addition schedules by day, crew shifts, packaging line rates by format, and a scheduler that tells you what happens to every downstream commitment when you insert a batch. The useful output is not a pretty Gantt chart. It is the answer to "if we brew this collaboration in week 3, what slips." Forecasting is the honest AI use case here: feed it 24 months of depletion data by SKU, account, and season, and it produces a demand forecast per SKU that drives a suggested brew schedule. It will not be right. It will be closer than the head brewer's gut on the eleventh SKU, and it frees him to override it on the three that matter. Pair it with raw material lead times and it flags that you need to lock in Citra 14 weeks before the schedule says you brew.

Problem: two facilities means two truths

The moment you open a second brewery, or a production facility separate from your original taproom, everything doubles and nothing consolidates. Inventory is per-site in the incumbent tools, transfers between sites are manual, and your COGS by SKU becomes a question nobody can answer confidently. Which site brewed the batch sitting in the Denver distributor's warehouse? Ekos will tell you, if the person who did the transfer entered it. Which site's overhead should carry it? Your controller decides, in Excel, once a quarter.

The off-the-shelf tools were built for the single-site brewery, which is most of the market, and that is a reasonable product decision on their part. Multi-site support gets bolted on as separate accounts you switch between. Consolidated reporting means exporting from both and merging. Transfer in bond between your own facilities is a compliance event with paperwork on both ends, and treating it as two independent inventory adjustments is how you end up explaining yourself to the TTB.

A custom build uses one data model with site as a dimension rather than a tenant boundary. A batch carries its origin site, its cost roll includes that site's actual overhead allocation, and a transfer in bond is one atomic event that debits and credits both facilities with matched records. Consolidated production, yield, and COGS reporting works because there was never a merge step. Roles and permissions are per-site so the Denver cellar lead cannot accidentally close a batch in Portland, while the CFO sees one number.

Cost and timeline, from Digital Heroes delivery experience

Across 2,000-plus delivered projects, a focused first release runs $60k to $130k and ships in 12 to 16 weeks. For a brewery that usually means one thing done properly: the keg ledger with offline scanning and distributor deposit reconciliation, or the transfer ledger with a compliant BROP. Pick the one bleeding the most and ship it standalone, reading from Ekos via export or API while the rest of your stack stays put.

A full platform covering production ledger, keg tracking, scheduling, multi-site, TTB and state reporting, distributor integration, and finance sync runs $150k to $400k phased over 6 to 12 months. What pushes a brewery build toward the top of that band: distributor EDI, because every distributor's 852 and 867 implementation is its own dialect and each one is real integration work; barrel-aged and blending programs, because proportional lineage across foeders is hard and the reporting has to survive an audit; multi-state excise, where each state's rules and filing formats are separate work; offline-first mobile, which costs more than a plain web app because sync conflict resolution has to be designed rather than assumed; and QuickBooks or NetSuite integration where COGS has to roll correctly per batch rather than per invoice. Taproom POS (Point of Sale) integration with Arryved or Toast is usually cheaper than people expect, since both have workable APIs.

Build vs buy: take the off-the-shelf tool seriously

If you brew under 6,000 barrels from one site, sell most of it through your own taproom, and have fewer than 20 wholesale accounts, Ekos or Beer30 is the right call and a custom build is a vanity project. Those tools have absorbed a decade of brewery-specific edge cases you would be paying to rediscover. The subscription is not the problem in your P&L. Buy it, use it properly, and put the capital in stainless.

The signals that it is time to build: you have a full-time or half-time person whose actual job is moving data between systems. Your BROP 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 program your ERP cannot represent, so it lives in a parallel spreadsheet. Or you are about to sign a distributor that requires EDI and your current stack has no answer. Any two of those together and the math has usually already turned, you just have not priced the reconciliation labor. At the 25,000 barrel and up breweries we have scoped, the annual carrying cost of the workaround stack, in salary and shrink and float, routinely exceeds the amortized cost of a build inside two years.

How to choose a developer for brewery management software

Ask them to model a blend on a whiteboard. Three foeders, two stainless tanks, one package run, correct volume attribution back to each source, and a BROP line that ties. A developer who has not done this will draw a parent-child tree and be wrong in about ninety seconds. This one question separates people who have built for breweries from people who have built inventory apps.

Ask what happens when the scanner has no signal. If the answer involves the user retrying, they have not built for a cellar or a cooler. Offline-first with a local queue and a defined conflict-resolution rule is the only correct answer, and they should be able to tell you what happens when two people scan the same keg on two devices.

Ask about their TTB and state excise experience directly, and ask who signs off. Compliance reporting is a legally binding output with your name on it. The right partner will insist your controller validates the report logic against real historical filings before go-live, and will build the audit trail in from day one rather than adding it when someone asks.

Ask who owns the code and where it lives. 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 a retainer, walk. And ask what happens to your Ekos history: any credible partner has a migration plan for your batch records, recipes, and SKU catalog before writing a line of new code, because a brewery platform with no history is a platform your team will not trust.