Wine Trade Accounting and Ledger Software Built on a Live Double-Entry Core

A Double-Entry Ledger That Never Trusts a Cached Total

Every transaction posts to a chart-of-accounts-based, immutable, append-only ledger, enforced at the database level so a raw insert can't bypass balance checks. Trial balance and account balances are computed live from the postings themselves on every read, never served from a cached figure.

Every Purchase Charge Posted on Its Own Line

A purchase rarely consists only of wine value. Delivery and handling charges are posted as their own separate, balanced general-ledger lines rather than being swept into a general expense line. Those charges are then capitalised against the specific units they arrived with, at a per-bottle rate. They are relieved into cost of goods sold at the exact moment those units sell, so the margin you read afterwards is the margin that actually happened, not an approximation that left carriage sitting somewhere else.

UK ABV-Based Duty, Effective-Dated

The duty and VAT engine calculates excise duty from a wine's ABV against effective-dated duty bands. A rate change between when stock was acquired and when it is eventually withdrawn is therefore calculated against whichever rate was in force on the day the movement happened, not a flat rate applied retroactively. A read-only preview calculator lets you check any scenario before anything posts.

Standard or Margin-Scheme VAT, on a Setting You Control

VAT is calculated under either the standard scheme or the margin scheme, as a per-book, effective-dated setting rather than a per-transaction choice. Standard VAT applies to the sale or acquisition value. Margin-scheme VAT applies to the difference between sale value and acquisition basis. Duty sits beside the VAT figure in the calculation, not folded into the base VAT is charged on.

Duty Suspended in Bond, Raised at Withdrawal

Because duty and VAT are raised on the withdrawal invoice at the point stock leaves bond, stock that stays in bond has nothing raised against it. Stock that already settled duty at a prior withdrawal is never charged it a second time on a later movement. Full detail on how this connects to bonded warehouse stock management.

A Ledger That Refuses to Fabricate a Number

Where a wine can't be priced or costed, the engine returns a structured "cannot compute" condition, never a fabricated zero. Cost-relief that's been stranded by an inconsistent posting history is detected automatically, but the write-off correction itself is always operator-triggered with a required reason — never an automatic silent sweep.

Postings Synced to Your Books, Not Re-Keyed

Ledger postings sync to your accounting platform through a queued, retried drain worker with attempt and deferral tracking. A posting made in Bacchus ERP therefore reaches your books without anyone re-keying it. See the specific platforms this connects to on the integrations page, and how it fits the wider fine wine ERP and wine trading software picture.

Reversals That Never Erase the Original

A sale or purchase can be reversed, and a general-ledger entry can be reversed on its own. Both post a compensating entry rather than deleting or editing anything, and neither can be undone twice. The audit trail stays visible in the admin UI as an explicit "Original" and "Reversal of #N" pairing. A correction is a fact recorded next to the mistake, not a mistake made to disappear.

A Sync Queue With Retries, Not a Fire-and-Forget Export

Postings destined for your external accounting platform sit in a queue drained on a scheduled interval. Attempt and deferral counters are tracked per row, and there is a reclaim path for anything that gets stuck, so a failed sync attempt is retried rather than silently dropped. Whichever GL adapter mode is active behind that queue, the queue mechanics, the retry logic, and the drain worker itself are the same real, running infrastructure. What varies by mode is only which system the postings ultimately land in.

Consignment Sales Post Themselves to the Ledger

When a consignment listing sells, the resulting sale doesn't wait on a person to key it into the books. The platform posts the sale, its revenue, and its cost-of-goods-sold entries automatically, using the same chart-of-accounts configuration the rest of the ledger runs on. That automatic posting is switched on by having the right account codes configured, not by a separate opt-in toggle. Configure the accounts once, and every consignment sale from then on lands on the ledger the moment it completes.

A Sale That Can Never Point at Nothing

Every posted sale is bound to its ledger entries at the database level. The sale row cannot be committed without the revenue and cost-of-goods-sold entries it points to already existing, and those entries cannot be deleted out from under it afterwards. That constraint holds whether the sale was keyed in by an admin or posted automatically by the platform. An automated posting is exactly as durably linked to its ledger entries as a manual one — the ledger was built that way deliberately, never a looser record because a person wasn't the one who typed it.