What a sub-10-employee brewery's monthly TTB reconciliation actually costs
By Yves Habchy · June 2026
What I am looking at
I am a software engineer. I am not a brewer. I have spent the last few weeks reading the surface that a sub-10-employee craft brewery sees on the day every month or quarter that the federal Brewer's Report of Operations comes due. The audit I started from pulled verbatim operator language off Capterra, G2, ProBrewer comparison threads, vendor-blog compliance guides, and the customer testimonial pages of brewery-specialist CPA firms. The shape that came out is consistent enough across vendors to be an architecture problem, not a vendor problem.
A typical 3-to-15-barrel taproom-bearing US craft brewery is running a brewing-OS (Ekos, Ollie, or Beer30), a point-of-sale (Square, Arryved, or GoTab), an accounting platform (QuickBooks Online or Xero), a federal portal at Pay.gov for the TTB BROP, a separate state portal for state excise, and a paper notebook the head brewer keeps for kettle losses and dump volumes. Five-to-six sources, none of which talk to each other cleanly. The BROP is an inventory ledger that has to reconcile against all of them. The TTB's own published burden estimate for filling Form 5130.9 is about one hour per filing. That number measures only the form-filling step. It does not measure pulling the numbers out of five systems and tying them out beforehand.
I have not run a brewery. The hours I am quoting below come from the operators who have.
What the industry says about itself
The Crafted ERP TTB-compliance guide, which is selling against the same pain to a different market tier, puts the shape cleanly:
"In most breweries, every number in the Brewer's Report has to come from different places, and none of these systems communicate automatically, which means someone has to manually extract data from each one, reconcile the numbers, and hope everything ties out before the deadline. For many breweries, that process consumes an entire workday every month."
That is the framing the industry uses about itself. A 2024 Doozy Solutions tech survey that the same guide cites reports 72% of mid-sized breweries and distilleries struggle with tax reporting due to disconnected systems and 67% report manual reconciliation consumes time that would otherwise go to production or sales. The numbers are vendor-curated; the shape is corroborated everywhere else I looked.
The workday-per-month cost is the upstream-reconciliation cost, not the form-filling cost. There is a $33/mo form-filling tool, TTB Tamer, that has been around since 2013 and markets a "saved hours" outcome for its narrow scope. It does not pull data from Ekos, or Square, or QuickBooks. The operator is still entering those numbers by hand. The hours that tool saves are the form-filling hours, not the upstream reconciliation hours. The upstream reconciliation is the larger pain and nobody is solving it.
Inside the named-vendor reviews, the same architecture problem keeps surfacing in different costumes. From an Ekos review on Capterra:
"Originally had issues with Ekos communicating with QuickBooks, Ekos wasn't able to send all invoices to QuickBooks when reference numbers were already used there."
An Ollie review surfaced in industry vendor-comparison coverage makes the same point about state-specific gaps:
"The program lacked certain data fields for North Carolina state reporting."
Vincent, a brewery owner on a ProBrewer comparison thread, surfaced the price-driven switching shape:
"Noticed a price hike in Ekos, switched to Ollie."
The vocabulary varies. The shape behind the vocabulary is one shape. Four record-keeping systems, four views of the same month of operations:
- The brewing-OS knows what was produced and what left in kegs to wholesale.
- The POS knows what poured in the taproom.
- The accounting platform knows which invoices got paid.
- The paper notebook holds the kettle losses and dump volumes that never made it into any digital system.
The federal form needs all four answers to agree. They do not agree on their own. Somebody does the agreeing, by hand, at the end of the month.
What I think is going on
Two non-negotiable external forces drive this and neither one is going away.
The first is the federal TTB Form 5130.9 filing cadence. Monthly for brewers producing more than ten thousand barrels per year. Quarterly via the simpler Form 5130.26 for everyone smaller who owes fifty thousand dollars or less in federal excise per year. Either way, due by the fifteenth day after the period closes. The form is an inventory ledger: beer produced plus transferred in plus transferred out plus removed taxable plus removed tax-free plus losses plus on-hand at end. Every line has to reconcile against the operator's records. The TTB publishes a list of common errors found during brewery audits and the top one is barrel-equivalent unit conversion mistakes, which is exactly the class of error that comes out of reconciling four different unit conventions across four different systems by hand.
The second is the three-tier distribution system that US post-Prohibition alcohol law forces. Producer to wholesaler to retailer. The brewery's own taproom is structurally a separate retail act inside the same legal entity, which is why taproom revenue lives in Square or Arryved and wholesale revenue lives in the brewing-OS's distributor module. The split is not a software bug. It is the legal architecture. Two physically separate accounting trails per pint.
These two forces are structural and not going anywhere. Every US brewery files some shape of the BROP at some cadence; the ones with a taproom and any wholesale are structurally over-fragmented across two parallel revenue trails on top of that. The pain renews every month or every quarter and the operators do not get to opt out.
What current tools do, almost without exception, is sell consolidation. BrewLedger, Beer30, Ollie, Ekos, Breww, Brew Ninja, Crafted ERP. The pitch is some variation of "switch to us and the gap disappears." Inside the brewing-OS, that works. Production numbers live in one place and the BROP auto-fills against them. Outside the brewing-OS, the operator still has Square or Arryved on the taproom side, QuickBooks for accounting, a state portal in their browser, and a paper notebook on the brewhouse wall. The cross-system part of the pain does not disappear when one platform absorbs the production module. It just moves.
There is one exception in the named landscape. BrewComply markets itself as a compliance layer that "integrates with your existing inventory software or accepts spreadsheet uploads." That is the closest existing thing to the layer this article is about. The scope is compliance-only, which leaves the taproom-versus-wholesale and the BROP reconciliation gaps open. Their public marketing does not name which inventory systems they sync against, which usually reads as either bespoke-per-customer professional services or a generic CSV-export adapter rather than packaged API-direct sync. A two-line email to their sales would clarify it. I have not sent one yet.
Outsourced brewery bookkeeping is the other real Layer-1 piece of the landscape. Small Batch Standard, Beer CPA, ClarkHirth, Amber's Bookkeeping. These firms own the trust-judgment-relationship axis at $150 to $1,000 per month for full-service, with the TTB filing bundled into the monthly close. They are not the competition for a $20-to-49-per-month layer-on-top tool. The competition they represent is the operator's judgment about whether the workday they are losing is more valuable than the bookkeeper they would have to hire. The operators who DIY-reconcile every quarter have already chosen against the bookkeeper price point.
The 2026 landscape has no AI-native cross-platform brewery reconciliation product. I went looking for one explicitly. The SoftwareWorld June 2026 "Top AI-Powered Brewery Software" listing is real, and every product on it operates intra-platform. Crafted ERP's AI layer is intra-NetSuite. Ekos's TTB Report Generation is intra-Ekos. None of them ingest from a heterogeneous brewing-OS plus POS plus accounting plus state portal stack. Cross-platform reconciliation is a data-pipe problem, not a generative-AI problem. Generic LLMs cannot log into Ekos and Square and QuickBooks and pull state autonomously. The integration layer is the moat.
What watching actually looks like
A tool that fits this architecture would run quietly against the operator's existing stack. Five jobs:
- Brewing-OS read. Production and packaging volumes from Ekos, Ollie, or Beer30. Via API where one exists (Beer30 publishes a REST API accessible via a sales-mediated key request). Via the operator's own credentials and a headless browser where one does not.
- Taproom read. Removals from Square, Arryved, or GoTab via their well-documented APIs.
- Accounting read. Invoice and payment state from QuickBooks Online or Xero via their well-documented APIs.
- Paper-log entry. A one-screen form the head brewer fills in for kettle losses and dump volumes. Realistic v0.1 substitute for OCR on a wet brewhouse notebook.
- Output. A filled-in TTB Form 5130.9 PDF the operator reviews and submits via Pay.gov themselves, plus a reconciled taproom-versus-wholesale view that catches the cross-trail disagreements before they get rolled into the form.
The federal Signing Authority stays with the operator. The tool never sits in the regulator's authorization chain. The wedge is preparation, not filing-as-vendor.
Honest constraints I am still working through
A few things I have not closed and want to be transparent about.
This article's verbatim quotes come from a sample I can replicate at higher density and have not yet. The Crafted ERP TTB-compliance guide is a direct URL anchor. The remaining quotes trace to a corpus-of-record across review aggregators, vendor-blog comparisons, and ProBrewer threads, where the underlying recurrence is what's load-bearing, not any one specific URL. The 2024 Doozy Solutions survey numbers are vendor-curated and I have not seen the underlying instrument. The ProBrewer.com thread surface, which is the canonical operator-voice comparison-thread surface for this category, I have sampled at three quotes against a target of ten-to-fifteen. The forum has a one-to-two business day commercial-verification gate before posting, which I am working through. The per-state operator quotes (California, Texas, Colorado, North Carolina, Michigan) are zero in my current sample against a target of three to five per state. None of these gaps shift the central finding about the cross-system reconciliation shape, but they would make the article's argument denser if I closed them.
A correction worth flagging on the technical side. Ekos publishes a thing called Craft Insights that is sometimes described as an API. Closer reading is that Craft Insights is a paid data-warehouse and BI-tool connector layer (Power BI, Tableau, Excel) sitting on top of the customer's Ekos subscription, not a developer-grade REST API that a third-party tool would integrate against. There is no public Ekos developer portal, no OpenAPI reference, no OAuth onboarding flow. A v0.1 ingest from Ekos in practice routes through CSV export or through a headless browser session running against the operator's own credentials, which is the same architectural pattern an analogous tool in the therapist-billing space uses to stay out of the centralized-PHI-handling business.
A correction worth flagging on the state landscape. The fifty-state excise-reporting picture is heterogeneous, not homogeneous. A few examples I went deeper on:
- California: CDTFA-501-BM, monthly, with Excel-template supplemental schedules.
- Colorado: DR 0442, monthly, with three required supplements.
- North Carolina: monthly via NCDOR; actually two separate forms (B-C-710 excise and B-C-715 shipping log per invoice), not one.
- Michigan: I had initially assumed this was an online-portal state like the others. The MLCC does not accept online submission of beer excise tax reports or payments at all. The forms and the Excel invoice attachment have to be mailed.
The operator-side paper-mail step is not erasable by a reconciliation tool. The state-coverage problem is harder than fifty drop-in connectors. Picking three to five high-density states for a first version is the realistic shape.
I am writing this for the operators and the operator-adjacent bookkeepers who already know all of this and can tell me which of it I have right and which of it I have wrong.
The ask
If you run, brew at, or do the books for a sub-ten-employee craft brewery on a heterogeneous stack (any combination of Ekos, Ollie, Beer30, BrewLedger, Square, Arryved, GoTab, QuickBooks, Xero, plus the federal Pay.gov BROP plus your state portal plus a paper notebook) and the monthly or quarterly reconciliation rings true, twenty minutes. No demo. No waitlist. If I am wrong about the shape of the gap, I would rather find out from one operator than from six months of building the wrong thing.
In exchange I will send back the aggregated reconciliation-time deltas across whatever sample of conversations comes out of this, plus whatever I learn about which workarounds actually catch the cross-system errors before the BROP is due. Anonymized. I will not put you on the record without explicit permission.
LinkedIn DM or yves.habchy@gmail.com. Happy to send a calendar link.