Distillery Management Software: Barrels, TTB, and When to Build

Why distillery software makes or breaks a high volume producer

Walk the rickhouse at any producer past 8,000 barrels and you will find the real system: a clipboard, a Sharpie, and a warehouseman named Dale who knows that rick 14 row C is actually the 2021 wheated mashbill even though the label says otherwise. The software of record is Whiskey Systems or Ekos or, at plenty of shops doing $30M in revenue, a workbook called TTB_MASTER_FINAL_v9_USE_THIS.xlsx with 31 tabs and a VLOOKUP that broke in 2023 and nobody noticed.

Here is what that costs. The compliance manager spends four to six days a month assembling the Monthly Report of Processing Operations (TTB F 5110.28), the Storage report (5110.11), and the Production report (5110.40). Each one has to reconcile to the others and to the transfer-in-bond records. When they do not reconcile, and they do not, somebody reverse-engineers the difference and writes an adjusting entry. That is guessing with a paper trail.

The concrete scene: a customer wants 40 barrels dumped for a single-barrel program, minimum 108 proof, from a specific 2019 rye run. Finding them means pulling the barrel table, filtering by mashbill, cross-referencing the last gauge (which was 14 months ago on a sample of six barrels), estimating angel's share by floor and by house, and then sending Dale to physically thief and proof candidates. That is nine days of lead time to answer a question the data should answer in four seconds. Meanwhile the sales director already promised the customer a two-week turnaround.

Problem: barrel-level truth does not exist, only barrel-level estimates

Your barrel record in Whiskey Systems has entry proof, entry date, fill wine gallons, and location. What it does not have is a defensible current proof for any barrel you have not physically gauged. So you carry a house evaporation curve, apply it uniformly, and the dump surprises you. In the barrel histories we have modeled, actual dump proof routinely lands several points off the house curve. On a 500-barrel dump that variance is real proof gallons, which is real excise tax, which is money you either overpaid or will owe with interest.

Off-the-shelf tools cannot fix this because they model the barrel as a row rather than an object with a physical history. No field for floor height. No field for rickhouse position. No temperature and humidity series. No relationship between the cooperage lot and observed loss. Ekos was built for breweries and bolted on spirits. Whiskey Systems knows TTB forms cold but treats the barrel as a static inventory unit.

A custom build models the barrel as a time series. Each barrel carries cooperage vendor and char lot, entry gauge, rickhouse, rick, tier, row, and every gauge event since fill. You wire in cheap wireless temp and humidity sensors per rickhouse floor, one per tier is enough, and store the readings. Then you fit an evaporation and proof-gain model per house, per floor, per mashbill, trained on your actual gauge history. This is the one place AI earns its cost outright: in our builds, a gradient boosted model trained on tens of thousands of your own barrel-gauge observations predicts current proof within roughly a point, close enough to plan a dump without thieving 200 barrels first. The system flags barrels where prediction confidence is low and tells Dale to go gauge those twelve rather than all of them. You are not replacing the hydrometer. You are telling the hydrometer where to go.

Problem: TTB reporting is assembled, not generated

Every operator says the same thing: the reports are not hard, they are just tedious. That is wrong. They are hard because the numbers come from four places that do not agree. Production says you made 1,842 proof gallons. Storage says you received 1,838. The four-gallon gap is an operator who wrote the tank gauge before dropping temperature, and the correction to 60F never happened. You find it on the 12th of the following month and back into it.

Off-the-shelf software cannot solve this because it accepts whatever you type. It validates format, not physics. Whiskey Systems will happily let you record a transfer that does not balance against the source tank, then produce a perfectly formatted 5110.28 that is quietly wrong. The form looks compliant. The underlying record is not.

A custom build makes the ledger the source of truth and the report a projection of it. Every movement of spirits is a double-entry event: proof gallons out of account A, into account B, with temperature, apparent proof, TTB Gauging Manual Table 1 correction, and Table 6 proof gallon computation applied at write time rather than at report time. The system refuses an entry that does not balance, the same way your accounting system refuses an unbalanced journal. Then the monthly reports are a query rather than a project. In the builds we have shipped, time from close to filed report drops from five days to twenty minutes, and the twenty minutes is one person reading the exception list.

The AI piece that pays for itself here is document extraction on inbound paperwork. Transfers in bond arrive as a PDF from the source DSP. Grain receipts, tanker BOLs, and cooperage invoices arrive as PDFs and photos. An extraction model pulls quantity, proof, permit number, and date, matches them to the expected receipt, and posts the entry for a human to approve in one click. That is a compliance clerk's entire Monday, gone.

Problem: distributor data arrives in 30 shapes and lands nowhere

You sell through Southern Glazer's in some states, RNDC in others, and eleven regional houses in the rest. Depletion reports come as CSVs, XLSX files with merged header cells, and in two cases a PDF someone scanned. VIP and iDIG cover part of it if you pay for them, and their SKU mapping still does not match yours, because your 750ml Bottled in Bond is item 44821 to you and BIB-750-KY to them.

Off-the-shelf tools do not fix this because distributor data integration is not what they do. Ekos ends at your dock. Your accountant handles the rest in Excel. The result: you cannot answer "which accounts bought my rye in Q3 and stopped buying in Q4" without a two-week analyst project, so you never ask it, and your brand ambassadors work off vibes and a Southern Glazer's rep's memory.

The custom build is an ingestion layer with a per-distributor parser, a SKU crosswalk table you maintain once, and an account master keyed to license number rather than name, because "Joe's Liquor" appears eleven ways across four files. Depletions land in the same warehouse as your production data. Now you have on-premise and off-premise depletion by account by week, and you can put it next to your barrel forecast. That is the actual point: knowing that Cincinnati depleted 340 cases of the single barrel program lets you know how many 2019 rye barrels to hold back, and holding the right barrels back is worth more than everything else in this document.

Problem: you cannot plan production against inventory you cannot see

The master distiller decides mashbill volume today for liquid that sells in six years. The tool for this decision at most producers is a spreadsheet the founder built and a gut feel. When the bourbon boom turns, and it does, you find out you are 4,000 barrels long on high rye and short on wheated, and neither problem is fixable in under four years.

Nothing off the shelf models this, because it is not an inventory feature. It is a forecast that has to combine your barrel population by mashbill and vintage, your predicted yield per barrel at dump, your depletion trend by SKU, your contract obligations, and your bottling capacity. Whiskey Systems does not know your depletions. Your BI (Business Intelligence) tool does not know your barrels.

What the build does: a forecast surface that runs your barrel population forward with the evaporation model, applies your blend recipes to convert barrels into finished cases by SKU, and lays projected supply against distributor depletion trend and contract commitments. Then it shows you the gap by quarter and by mashbill, five years out, and updates weekly as real gauge data arrives. The decision is still the master distiller's. It is now a decision made against numbers rather than against a feeling about the category.

Problem: bonded premises boundaries are a data model, not a floor plan

Multi-site producers get this wrong constantly. You have a DSP in Kentucky, a second bonded warehouse across the county line, and a bottling operation that is separately registered. Every movement between them is a transfer in bond with its own paperwork and its own tax implication. When a barrel moves and the software treats bonded premises as a text field on the barrel record, you have already lost.

Generic tools model one facility well. Add a second bonded premises and you are running two accounts and reconciling by hand, which is precisely when transfers go unrecorded and a TTB audit finds a barrel that exists in two places.

The build treats each registered premises as a first-class entity with its own bonded account, its own tax determination point, and enforced rules on what movements are legal between which pairs. A barrel cannot move without generating the transfer record. The 5100.16 and the transfer documentation generate from the movement event rather than from someone remembering to do the paperwork Friday afternoon. For a producer running three permits, this alone is the reason to build.

What this costs and how long it takes

Across 2,000-plus projects, our delivery bands hold well here. A focused first release, meaning the barrel ledger with gauge history, the double-entry proof gallon engine, and generated 5110.11 / 5110.28 / 5110.40, runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding distributor ingestion, the forecast surface, multi-premises transfer control, and bottling line integration runs $150,000 to $400,000 phased over 6 to 12 months.

What drives price up in this category: number of registered premises, because each one multiplies the transfer rules and the reporting surface. Number of distributors, because each parser is real work and Southern Glazer's format changes without notice. Whether you need the evaporation model, which requires sensor installation and at least a season of gauge data before it earns trust. Whether you are integrating a bottling line PLC or a Krones filler, because industrial integration is a different discipline than web software and priced accordingly. And migration: fifteen years of barrel history in Excel with inconsistent mashbill naming takes four to six weeks to clean before it is worth loading.

Build versus buy: take the position

Stay with Whiskey Systems if you are under roughly 3,000 barrels, one bonded premises, and selling mostly DTC and local. It knows the forms, it costs a fraction of a build, and every dollar you would spend on custom software is better spent on barrels. Stay with Ekos if you are a brewery that also distills and beer is the majority of your volume. These tools are good at what they do.

Build when three signals show up together. First: you have more than one bonded premises and someone is reconciling between them by hand. Second: a person on payroll spends more than three days a month assembling TTB reports, which you can price directly against your compliance manager's salary before you count the error risk. Third: you have turned down or fumbled a program, a single-barrel account, a private label, a contract fill, because you could not answer an inventory question fast enough. That third one is the expensive signal, because it does not show up on any P&L line. It shows up as revenue you never booked.

If two of those three are true, run the numbers. If all three are true, you are already paying for the custom system in labor and lost deals, you just are not getting the software.

How to choose a developer for distillery management software

Make them explain proof gallon math without notes. Ask how they compute proof gallons from a tank gauge at 74F. If they do not immediately reference temperature correction against the TTB Gauging Manual tables before multiplying, they will build you a calculator that produces wrong numbers with total confidence. This is the fastest filter and it takes ninety seconds.

Ask to see their barrel data model before they write a line of code. The right answer has barrels, gauge events, and locations as separate entities with time-scoped relationships. The wrong answer is a barrels table with a current_proof column. If they show you the wrong answer, everything downstream, forecasting, dump planning, loss analysis, is built on sand and will need rewriting in year two.

Ask what happens when Southern Glazer's changes their file format. The answer you want is a parser layer with per-distributor adapters, schema validation on ingest, and an alert when a file fails to match rather than a silent partial load. The answer you do not want is "we will handle it." You want to know the format will change and the system is built expecting it.

Ask who owns the code and get it in writing before the deposit clears. You should own the repository, the schema, and the deployment. If the answer involves a license, a platform fee, or a hosting arrangement you cannot exit, you are renting a dependency with your compliance data inside it. Full ownership, source in your GitHub org, from day one.