What is order accounting?
Order accounting is the reconciliation surface: one row per order carrying every financial fact about it — revenue excluding and including tax, VAT, shipping charged, the goods and shipping refunded against it, and its contribution margin. It exists for the moments when an aggregate looks wrong and you need to see the actual orders, and for handing an accountant numbers that tie back to individual order references.
Formula
excl-tax revenue = line revenue − order discount
incl-tax revenue = excl-tax revenue + VAT
one row per order, with shipping charged, goods refunds, shipping refunded
and margin alongside
Worked example
Order #4821: 3 items, €96.50 excl tax, €18.34 VAT, €114.84 incl tax, €4.95 shipping charged, one €22.00 partial goods refund, €4.95 shipping refunded, €31.20 margin (32.3%). The €22.00 sits in "Goods refunds" and the €4.95 in "Shipping refunded"; neither moves the other, and the shipping refund leaves the margin where it was. The platform back office shows €119.79 for this order — incl-tax plus shipping — and the analytics dashboards show €96.50. Both are on this one row, which is the point: every reconciliation between the store, the books and the dashboards routes through here.
How Saldo Metrics computes it
v_order_accounting assembles each order from the facts: line revenue summed per
order minus the order-level discount (the excl-tax basis every analytics widget
uses), the order's tax total, their sum as the incl-tax figure, shipping charged,
goods refunds summed from the refund events, refunded shipping summed from
canonical.fact_shipping_refund, and contribution margin under the
order-grain cost rule — an order with any uncosted line shows unknown margin,
never zero, with its revenue flagged uncosted. The margin column books every
non-cancelled order, fully refunded ones included: it reads v_contribution_margin_all,
the same booked population the P&L and net operating profit use, not the net-sale
view. That is why a fully refunded order still carries a margin figure here — usually
negative, since its shipping and any marketplace fees were already spent while its revenue
has fully reversed. Each row keeps the order's source reference, status, and both
the is_net_sale and is_booked flags, and the widget serves the most recent
orders filterable by period, country and status. All amounts are EUR conversions
at the order's own date; the original currency stays on the underlying facts.
Why it matters
Analytics and accounting count differently on purpose — net sales versus placed orders, excl-tax versus incl-tax — and without a bridge those differences read as bugs. This view is the bridge: any dashboard total can be decomposed into rows here, and any row tied back to the store platform by its order reference.
Common mistakes
- Summing incl-tax revenue as "revenue". VAT is collected for the tax office, not earned; every performance metric uses the excl-tax basis.
- Expecting cancelled orders to be absent. The view carries every order with its status; it is the filterable superset, unlike the pre-filtered net-sale metrics.
- Adding "Shipping refunded" to "Goods refunds". "Goods refunds" (the export's "Refunded (goods)") is goods only and feeds the margin reversal; refunded shipping is a separate column that never touches margin. Summing them and netting the total against margin takes the shipping off product revenue that never contained it.
- Reading NULL margin as zero. NULL means uncosted — the margin is unknown until product costs land, and the margin percent column stays honest by showing nothing.
Where you see this in the app
The Orders (Accounting) dashboard widget and the accounting report templates.