Beverage Alcohol Compliance Software Problems: The 7 That Stop You Selling, and How to Avoid Them

Why does the registration data model get scoped wrong so often?

Because the obvious model is wrong and it looks right. Most teams draw a product table and a many to many link to states, which reads as a sensible design in a kickoff meeting. Your actual obligation is per product, per label version, per size, per state, and in some cases per brand owner or supplier. Three hundred SKUs across twenty states is thousands of registration records, each carrying its own effective date, expiry and renewal rule, because some states renew annually, some biennially, and some registrations persist until something changes.

The word changes is where the model breaks. A supplier reformulates, redesigns a label, or moves to a different bottle size. That is a new federal label approval and, in many states, a new registration. If your system holds one row per SKU, nothing about that event is representable, so the row stays green and the sales team keeps selling.

The fix is three linked records rather than one: the SKU, the label version, and the registration. A new label version starts registered nowhere until each state says otherwise, which means the default behaviour is a block rather than a silent pass. Supplier packaging change notifications feed the same queue that renewals do, so compliance learns about a label refresh from the system instead of from a case arriving in the warehouse. Ask any developer to explain what happens when a supplier changes a label, and stop the conversation if the answer does not separate those three records.

What goes wrong when you migrate the registration and posting history?

The uncomfortable part of this category is that migration is not a data exercise, it is an audit. Reconstructing an accurate current registration and posting state across your portfolio and your states surfaces gaps, and most companies find some. A spreadsheet with an approved column and no date. A filing everyone assumed was accepted that was never acknowledged. A registration renewed by a person who left in 2023 and whose renewal confirmations went to a mailbox nobody monitors.

Loading that into a new system as if it were clean is how a build becomes a liability. The system then reports confidently on a state it does not actually know, which is worse than the spreadsheet, because the spreadsheet at least made the compliance manager check.

The fix starts by allowing a third status. Every registration record should be able to say accepted, rejected, or unknown, and unknown should be the default for anything migrated without evidence. Attach the archived filing document to the record so a claim can be checked rather than trusted. Work your top revenue states first so the reconstruction produces commercial protection early rather than perfect coverage late. And give the reconstruction a named owner with time allocated, because it is the item most likely to move a timeline and it has nothing to do with engineering. Those gaps exist whether or not you build anything, which is the argument for finding them deliberately.

Why do ERP (Enterprise Resource Planning) and order entry integrations break after launch?

A compliance check that order entry does not call is decoration, and there are four reliable ways that link degrades after go live. A new item gets created in the ERP with no matching compliance record, so the check has nothing to answer with and either passes it or blocks everything. The posted price is stored in both systems and the copies drift, so what was filed and what is charged stop matching. The service is slow one afternoon and somebody adds a bypass to keep orders flowing. Or a rep works offline and the order syncs afterwards, when the check no longer sits between the quote and the acceptance.

The fix is to design each of those cases before launch rather than discovering them. Item creation in the ERP should raise a compliance record in a pending state automatically, so a new SKU is blocked by default instead of unknown. The posted price should live in one place and be pulled by the ERP rather than copied into it, which removes the drift entirely. Decide explicitly, with counsel, whether an unreachable check blocks or warns, and write the answer into the design rather than leaving it to whoever is on call. Log every bypass with a person's name attached and review the log weekly, because bypass volume is the earliest signal that the check is rejecting things it should not.

What happens when trade licence validation is not covered?

You ship to a retailer whose licence lapsed, and the retailer does not tell you. There is no event in your order flow that would surface it, because their licence status is a fact about them held somewhere else. The order looks identical to every other order, and the violation is yours.

The direct to consumer version is worse because the limits are per consumer and per state and they have to be enforced at the point of sale (POS) rather than discovered in a monthly report. A report that tells you a customer exceeded a volume limit last month is not compliance, it is documentation of a breach.

The fix is to hold licence status and a last verified date on every trade customer, revalidate on a schedule against published state licence data where it exists, and make an expired licence block a shipment rather than generate a report someone reads later. Give unverifiable a status of its own, because a customer you could not check is a different risk from one you checked and cleared, and collapsing the two hides the problem. For direct to consumer, enforce volume limits, permitted destinations and age verification in the order path itself, and record the check result on the order so the evidence exists later. None of this replaces advice from alcohol beverage counsel on your specific obligations, and the design should assume your rules will change.

Should you build custom or configure what you already own?

Buy, and do not commission anything, if you operate in a handful of states with a modest portfolio, or if you are a winery whose main compliance surface is direct to consumer shipping. Sovos ShipCompliant is the right answer for a great deal of that market, its rules content is deep and actively maintained, and it will cost far less than a build. If you would rather outsource the operation than run it, Park Street exists for exactly that and it is a legitimate strategy. If your problem is tax determination, Avalara does that job.

There is one thing nobody should build: a fifty state rules library. Maintaining current alcohol regulation content across states is a serious ongoing content operation and it is the core product of the compliance platforms. Either consume a commercial feed or hold the rules your compliance team already maintains in a data store they can edit.

Build the operating system around bought rules content when two or more of these are true. The calendar is a full time role and the risk sits in one person's spreadsheet. Reps regularly quote items that turn out to be unregistered or unposted. Your supplier depletion reporting burden is large, since that is contractual work no compliance platform will do for you. Your portfolio changes constantly through new supplier agreements. Or per SKU per state pricing has started to scale badly against a wide portfolio.

How do hidden costs get into the quote?

They arrive as single lines that are actually many. The ones that move numbers in this category:

• States counted as a quantity. Each state brings its own rule set, its own forms and its own acknowledgement behaviour, so twenty states is not twice the work of ten.
• Generating filings versus tracking them. Producing submissions in state specific formats is a much larger effort than recording that a filing is due, and quotes rarely say which one is included.
• Direct to consumer. Permits, per consumer volume limits, age verification and carrier requirements form a subsystem of their own rather than a feature.
• Multi entity structures. Common in importers with separate licensed entities, and every rule then has to know which entity holds which licence in which state.
• ERP integration depth. A real time check inside order entry is a different project from a nightly export, and only one of them prevents a rep quoting an unregistered item.
• Rules maintenance treated as free. Someone has to keep the content current after launch, and if that is not a named role with a budget it will not happen.

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

The builds that work make a rule change a data change. If adding a state requirement or shifting a posting window needs a code release, your compliance team will route around the system within two months and you are back to the spreadsheet with extra steps.

They also take the rejection message seriously. When order entry blocks a rep, the message needs the reason, the expected resolution date and a named contact. A generic validation error teaches reps to work around the system, and once that habit forms the check stops protecting anything.

They model acknowledgement explicitly. An assumed filing and an accepted filing are different things and only one of them lets you sell, so a status field with pending, accepted and rejected is not a detail, it is the difference between a system that reports truth and one that reports intent.

Finally, settle ownership before kickoff, in writing, covering the repository and the cloud accounts. This system decides whether you may sell in a state. It should not depend on a supplier relationship you cannot exit, and any developer who hedges on that question has answered a different one.