Ledger
Accounting postings in Omnium — how sales, VAT, tender, and gift cards are turned into balanced double-entry vouchers for export to your ERP or accounting system.
The Ledger turns the commercial activity that flows through Omnium — POS sales, web and click & collect fulfillment, returns, gift cards, and tender — into balanced double-entry accounting postings. Each posting is a voucher: a set of ledger lines whose debits equal credits, ready to export to your ERP or accounting system.
Postings are generated automatically from two sources:
- POS Z-report close — when a register's Z-report is settled, Omnium builds the posting for that register inline.
- Web fulfillment — a daily batch posts the orders shipped from each store on the previous accounting day.
Every line carries the GL account, debit/credit amount, VAT code, VAT rate, and tax-group code, so the resulting voucher is self-describing and reconcilable.
The Ledger is off by default and enabled per tenant. Posting generation and the tax-group subsystem are independent switches — you can run VAT-coded settlement reports without enabling full postings, and vice versa. See Configuration.
In this section
Key terms
| Term | Meaning |
|---|---|
| Posting | A voucher header summarising one balanced set of ledger lines. One posting per source event (a Z-report close, or one store's fulfillment day). |
| Ledger line | A single debit or credit entry against one GL account. A posting has many lines. |
| GL account | A general-ledger account number in your accounting system. Omnium books each line to one account. |
| Chart of Accounts | The tenant's mapping from Omnium events (sales at a given rate, a tender type, a gift-card sale) to GL account numbers. |
| Tax group | A tenant-defined VAT code carrying a rate and an ERP/SAF-T external code (MVA-kode). Tags products, prices, and lines. |
| Source | Where a posting came from: PosZReport or WebFulfillment. |
| Posting hash | A deterministic hash over a posting's identity and lines, used to detect changes and keep historical postings byte-stable across regeneration. |