What a Wine Trade Ledger Has to Record

A Generic Double-Entry Ledger Is Necessary But Not Sufficient

Every wine merchant needs a proper double-entry ledger underneath their business: chart of accounts, immutable postings, a trial balance that reconciles. That part genuinely is general-purpose accounting infrastructure, no different in principle from what any business needs. But a ledger that only knows how to post generic sales and purchases misses almost everything specific to how the wine trade actually generates entries. Duty and VAT fall due at a different point than the sale itself. Stock is sold before it physically lands. Consignment sales generate two linked documents instead of one. Reversals have to be traceable rather than simply deleted. A wine trade ledger has to produce all of these correctly. Otherwise a merchant ends up bolting a second, informal system on top of the "real" ledger to track the parts it cannot handle — which is exactly the kind of disconnected record-keeping that causes reconciliation problems at year end.

Immutable, Append-Only Postings

The first requirement is structural rather than wine-specific. Financial postings need to be immutable and append-only, so a posting once made can never simply be edited or deleted out from under an audit trail. Corrections have to be made by posting a compensating entry, not by rewriting history. That matters more, not less, for a trade that routinely reverses transactions — a cancelled sale, a returned case, a corrected duty calculation — and needs every one of those corrections to stay visible rather than be silently erased. A trial balance and account-balance reconciliation should also be computed live from the actual postings, not from a cached running total that can drift out of sync with what was really posted.

Duty and VAT Postings, Raised at the Right Point

Because excise duty and VAT on bonded wine become due at withdrawal rather than at the point of sale or purchase, a wine trade ledger has to raise a distinct withdrawal invoice. That invoice carries the duty and VAT calculated against the rate in force on that specific date, separately from the underlying sale or purchase posting. HMRC's own rules setting the point at which duty and VAT become due on wine moving out of a bonded warehouse are published in Excise Notice 197, which is the authoritative reference for when the duty point actually falls. See our companion guide on how duty and VAT are calculated on wine moving out of bond for the mechanics of that calculation. The ledger's own job is narrower: make sure the resulting figure lands as its own correctly timed posting, rather than being folded, inaccurately, into the sale price at the point the sale was agreed.

Multi-Line Purchase Postings, Not Just a Single Value Line

A wine purchase is very rarely just "wine value." It typically also carries delivery and handling charges, and those need their own separate, balanced GL line rather than being absorbed silently into the cost of the wine itself. A ledger that posts a single value line per purchase understates what is actually being spent on logistics versus stock. It also makes it harder to see whether those charges are being capitalised into inventory correctly or expensed in the period they were incurred. Getting this right matters for margin reporting too. If delivery and handling charges are capitalised into a unit's cost, they need to be relieved into cost of goods sold at the point that unit is eventually sold — not left permanently on the balance sheet, overstating inventory.

Sales-in-Transit as a Deferred Claim, Not a Premature Posting

Wine can be sold while it's still in transit, agreed and invoiced to a buyer before the shipment has physically landed. A ledger needs a way to represent that honestly: as a deferred claim, with no money posted and no stock moved until the shipment actually lands. At that point the sale completes itself against the newly landed position. Posting the sale prematurely risks recognising revenue against stock that is not confirmed yet. Refusing to record the sale at all until landing understates a merchant's real pipeline. A ledger built for the trade needs the middle ground: a real, visible commitment that only converts into an actual posting once the underlying stock genuinely exists in the merchant's control. An en primeur campaign is the same problem stretched over years rather than weeks, and it is exactly why our en primeur allocation software keeps a campaign commitment visible from the moment it is made rather than treating it as unposted until the wine physically lands.

Consignment and Brokering: Two Linked Documents From One Event

When a client's own consigned stock sells through a merchant's brokering arrangement, that single sale event needs to generate two linked financial documents at once. One is a sales order to the buyer. The other is a purchase order representing the merchant's own acquisition of the stock from the consigning client, net of commission. Both need to post atomically, in the same transaction as the state change from "listed" to "sold." If those two documents can drift out of sync — one posts, the other fails, or they are generated at different times — the ledger no longer reflects what actually happened in a single commercial event. Untangling that discrepancy afterwards is exactly the kind of manual reconciliation a well-built ledger should make unnecessary. This is also why consignment and brokering run as part of the same system that handles a merchant's day-to-day trading rather than as a bolt-on, which our wine trading software page covers in full.

Reversals That Are Traceable, Not Just Deleted

Sales and purchases in the wine trade get reversed more often than in many other retail categories. A client changes their mind before delivery, a case turns out to be faulty, a duty calculation needs correcting. A wine trade ledger has to handle that by posting a compensating entry rather than deleting the original. The audit trail has to link the reversal back to what it reverses — "Original" and "Reversal of #N," not a blank space where a transaction used to be. It also needs a guard against reversing the same transaction twice, because a double reversal is itself a real accounting error rather than a harmless no-op.

The Company-to-Client Ownership Change, as Its Own Posting Event

The single ledger event most worth getting right is moving stock from a merchant's own company-owned holding into a client's holding as part of a genuine sale. It is the point where a wine merchant's real books diverge most sharply from a generic retail ledger. That transition needs to post atomically: the buyer's holding lands on the position and unit ledger in the same transaction as the ownership change itself, with guardrails preventing a client from being sold stock they already own. For the record-keeping side of the same event, see our guide to tracking provenance across a change of ownership. The ledger and the provenance record both have to agree, because they are two views of one underlying event.

What This Adds Up To

None of these requirements individually is exotic. Each one is a specific, real consequence of how wine actually moves through bonded storage, changes hands, and gets sold on consignment. Taken together, though, they are a meaningfully larger set of postings than a generic sales ledger is built to produce. That is exactly why a wine trade ledger needs to be purpose-built around this set of events, rather than adapted after the fact from software designed for a different kind of retail business. For the full case on why the wine trade needs its own systems rather than a generic ERP adapted to fit, see our why the fine wine trade needs its own ERP page. For the accounting side specifically, see wine trade accounting and ledger software, or the platform as a whole on our fine wine ERP software page.