How order financials flow to accounting
Every sales order carries two kinds of money: the amounts your customer sees — revenue, discounts, tax, shipping — and the double-entry bookkeeping those amounts become inside your accounting software. This page explains how the first turns into the second: how each line's numbers roll up into a single accounting transaction, how each amount is mapped to a nominal code, and how an order priced in a foreign currency still posts cleanly to your books.
Understanding this matters when a figure in Xero doesn't look the way you expect — because almost every number there is derived, on a fixed set of rules, from the order in SKU.io.
Where order money lives
Before any accounting happens, an order's financial amounts sit in three places.
| Record | What it holds | When it's created |
|---|---|---|
| Line financials | Per-line revenue, discount, tax, and cost/COGS — the numbers behind the Profit tab. | Auto-seeded the moment a line is created; every product line always has one. |
| Financial (charge) lines | Order-level charges such as shipping, handling, or a miscellaneous fee, each with its own type and tax. | When you add a charge. |
| Accounting transaction | The double-entry, nominal-coded posting for the whole order — what actually syncs to your accounting software. | Generated from the order (see When the transaction is built or removed). |
Line financials are seeded automatically so the Profit tab and the accounting rules always have something to read — you never create them by hand. Charges you add explicitly, and only the ones classified as revenue (shipping and the like) reach the accounting transaction; a pure cost charge stays out of the sales posting.
From a line to the ledger
When SKU.io builds the accounting transaction, it walks every product line and every revenue charge line, converts each into balanced debit/credit entries, and stamps the result with your order's number and date.
The transaction is created once per order, dated to the order date, and referenced by the sales order number. It's a sales invoice transaction — SKU.io has no separate first-class invoice record, so an "invoice" is this transaction plus a printable PDF.
This transaction records revenue, discount, and tax at the order level. The matching cost of goods sold is realized separately, only when stock actually ships — see How fulfilling moves inventory and realizes COGS. That's why an unshipped order can show revenue in your books while its COGS is still pending.
The accounting transaction, line by line
Each product line expands into a small set of balanced entries. Take one line on order SO-DOCS-0001 for Blue Bottle Retail — 10 × Stainless Water Bottle 750ml at $20.00, with a $20.00 discount and $18.00 of tax:
| Entry | Type | Amount | Meaning |
|---|---|---|---|
| Accounts Receivable | Debit | $198.00 | What the customer owes — revenue minus discount plus tax (the net). |
| Sales revenue | Credit | $200.00 | Gross revenue for the line, at the line's revenue nominal code. |
| Discount | Credit | −$20.00 | A negative credit (contra-revenue) that reduces recognized revenue. |
| Sales tax | Credit | $18.00 | The tax collected, to your sales-tax liability code. |
The credits net to $198.00, exactly matching the Accounts Receivable debit, so the transaction balances. Revenue charge lines (shipping, handling) expand the same way: a receivable debit plus a revenue credit, with their own discount and tax legs when present.
If an order is priced tax-inclusive, SKU.io strips the tax back out so revenue is recorded net and the tax sits on its own line — your revenue figure is never inflated by tax baked into the sticker price.
Nominal codes: Where each amount posts
A nominal code (also called a ledger or GL account code) is the account each amount lands in. SKU.io resolves a code for every entry, falling back to your account-mapping defaults when a line has no more specific one:
| Entry | Resolved from |
|---|---|
| Accounts Receivable | Your global Accounts Receivable mapping. |
| Line revenue | The product line's own nominal code, else the default sales nominal code. |
| Shipping revenue | The shipping charge line's code, or the channel's shipping-revenue code, depending on your settings. |
| Discount | The discount nominal code for the order's channel (or sub-channel). |
| Sales tax | Your global sales-tax mapping. |
Because codes resolve per line and per channel, two orders with identical products can post revenue to different accounts if they came from different sales channels or the lines carry different codes. That's deliberate — it lets you split revenue by product category or marketplace in your accounting software without any manual re-coding.
Syncing to your accounting software
Once built, the transaction can push to your connected accounting software (such as Xero). Whether it does is governed by a setting rather than an on-the-spot choice:
- Manual and SKU.io-native orders follow a single global switch for syncing sales-order invoices.
- Marketplace/channel orders follow a per-channel switch, so you can sync Shopify invoices while holding back another channel's.
From an order's Accounting tab you can view the built transaction and its lines, and act on it with two icon buttons above the transaction card — Rebuild transaction (re-derives it from the order's current figures) and Sync to accounting (pushes it to your connected software; shown only once an accounting integration is connected). For high-volume channels such as Amazon, invoices can be flagged batchable so many orders post as a consolidated transaction instead of one per order — keeping your ledger readable.
When the transaction is built or removed
The accounting transaction isn't static — it's rebuilt or torn down as the order changes.
| Action | Effect on accounting |
|---|---|
| Generate Accounting Transaction (Accounting tab) | Builds — or rebuilds — the transaction from the order's current lines and charges. |
| Recalculate Financials (Profit tab) | Re-seeds the per-line revenue/discount/cost figures the transaction reads from. |
| Revert to draft | Deletes the transaction — a draft has nothing to post. |
| Cancel | Deletes the transaction as part of unwinding the order. |
| Issue a sales credit | Posts its own accounting transaction (a credit note), linked to the order's as a child. |
Reverting or cancelling an order removes its accounting transaction outright; the Accounting tab then shows a banner offering to generate a fresh one. Recalculate Financials does something different — it refreshes the underlying line numbers (for example after editing quantities or prices) so the next generate posts the corrected figures. If your books look stale after an edit, recalculate first, then regenerate.
Refunds and credits flow back through the returns, credits, and refunds pipeline; each sales credit carries its own posting rather than editing the original invoice, so your audit trail stays intact.
Multi-currency orders and the FX snapshot
An order can transact in your customer's currency while your books are kept in your base (tenant) currency. SKU.io reconciles the two with a rate captured once, at order time.
- The order stores the transacting currency (what the customer is billed in) and a base-currency snapshot taken when the order is created.
- Every line exposes its amount and tax converted to base currency at that snapshotted rate. The accounting transaction posts entirely in base currency, so your ledger never mixes currencies.
Say Blue Bottle Retail places SO-DOCS-0001 in EUR while your base currency is USD, and the rate on the order date is 1.08. A €200.00 line posts as $216.00 in the accounting transaction, and its tax converts on the same rate.
The FX rate is snapshotted when the order is created and doesn't drift with the market afterwards. If exchange rates move before you ship or invoice, the order keeps posting at its original rate — which is what you want for a historical sale, but means a re-generated transaction reflects the order-date rate, not today's. To post at a different rate, you'd create a new order.
Next steps
- Generate invoices, packing slips, and accounting — the steps to produce the PDF and (re)generate the transaction
- Add discounts and charges — how the amounts on this page get onto an order
- Record payments and apply store credit — the money coming in against these invoices
- Process returns: RMAs and credits — issuing credit notes
- How fulfilling moves inventory and realizes COGS — the cost side of the ledger
- Returns, credits, and refunds — how money-back postings work
- Glossary — nominal code, accounting transaction, financial line