Ecommerce to Accounting Handover Guide
FINANCE HANDOVER
Hand over explainable control totals, not a pile of order records
Accounting needs to connect sales, tax, refunds, fees and cash settlement. The handover should show how storefront events become ledger entries and how every difference is investigated.
01 – EVENT
Define the accounting trigger
Choose the order or settlement status that creates each invoice, credit, payment, fee and stock-value event.
02 – CONTROL
Reconcile independent totals
Compare store orders, gateway payouts and ledger entries by period, currency and payment method.
03 – EXCEPTION
Own every unmatched item
Route missing mappings, partial refunds, chargebacks and timing differences to a visible queue with an owner.
Reconcile one complete settlement cycle in a test organisation
Include a normal sale, discount, shipping charge, tax, fee, refund and delayed payout so the handover proves the difficult path, not only a simple order.
An ecommerce accounting handover is complete when finance can move from a bank deposit back to the payment settlement and the underlying orders without guessing. Orders alone are insufficient because gateways commonly settle several transactions together and may deduct fees, refunds or chargebacks before cash reaches the bank.
Use the Xero handover service when mappings, clearing accounts or exception ownership are unclear. The next guide, Ecommerce to Xero Accounting Handover, applies this control model specifically to Xero.
1. Agree the accounting boundary
List the systems that create commercial facts: ecommerce platform, payment gateway, marketplace, point of sale, inventory system, bank and accounting ledger. For each fact, name one authoritative source. The ecommerce platform may own order lines and customer-facing tax; the gateway owns settlement details and fees; the bank owns cash received; the ledger owns the final accounting classification.
| Business fact | Likely source | Handover question |
|---|---|---|
| Order and line values | Ecommerce platform | Which statuses are included and in which timezone? |
| Payment and payout | Gateway or marketplace | How are transactions grouped into deposits? |
| Fees and chargebacks | Gateway statement | Are fees grossed up and separately coded? |
| Refund and credit | Store plus gateway | When is the credit recognised and when does cash leave? |
| Stock movement and cost | Inventory owner | Which event changes quantity and inventory value? |
| Bank receipt | Bank feed | Which clearing balance should it settle? |
2. Define the transaction contract
Write the fields required for every accounting event: source order, transaction ID, timestamp, currency, gross sale, discount, shipping, tax, refund, fee, net amount, payment method and settlement reference. Add stable SKU and tax mappings where line-level entries are required. Version the mapping so a historical transaction can be interpreted after the configuration changes.
- Use source IDs as references; do not rely on customer names or rounded amounts as unique keys.
- Preserve original currency and conversion evidence where more than one currency is involved.
- Separate discounts from refunds because they occur at different stages of the sale.
- Separate payment-processor fees from net sales rather than posting the bank deposit as revenue.
- Record cancelled, failed and test orders so they can be excluded consistently.
3. Choose the posting level
| Model | Useful when | Control risk |
|---|---|---|
| One invoice per order | Customer-level receivables and line history are required in the ledger | High transaction volume and duplicate customer or item records |
| Daily summary | Operations retain line detail and finance needs controlled daily totals | Weak references can make payout differences hard to trace |
| Payout summary | The gateway settlement is the natural accounting batch | Timing and refunds must still connect to order periods |
| Hybrid | Some channels or customer classes need detail and others need summaries | Different methods need an explicit boundary and separate controls |
Choose the lowest level of detail finance needs for tax, customer accounts, inventory valuation and audit. Sending every click or order note into the ledger adds noise. Sending only net bank receipts hides sales, tax, fees and refunds. The right model preserves traceability without turning accounting software into the operational order database.
4. Use clearing accounts to bridge timing
Xero documents the use of a clearing account for bulk online payments: order payments are applied to the clearing account, the bank deposit is allocated to the same account, and merchant fees or refunds are recorded separately. The clearing balance should then explain transactions not yet settled, timing differences or errors rather than becoming a permanent unexplained amount.
5. Build daily and period-end controls
| Control | Expected equation |
|---|---|
| Sales control | Gross sales minus discounts plus shipping and tax equals order total |
| Refund control | Store refunds connect to credits and gateway cash movements |
| Settlement control | Gross settled transactions minus fees, refunds and chargebacks equals payout |
| Cash control | Gateway payout equals bank receipt, allowing documented timing |
| Clearing control | Opening balance plus movements minus bank settlements equals explainable closing items |
6. Design the exception queue
- Duplicate source reference or attempted reposting.
- Unknown product, customer, tax, currency or account mapping.
- Payout with no matching settlement detail.
- Refund recorded in one system but missing from another.
- Manual order edit after the accounting event was posted.
- Difference outside the approved rounding or timing rule.
Each exception needs the source IDs, detected time, financial impact, owner, action and resolution evidence. Do not silently create a suspense mapping for every unknown item. A visible queue protects the books and exposes upstream data problems that should be fixed at source.
Worked settlement example
A gateway settles several paid orders in one bank deposit. The settlement includes product sales, shipping and tax, subtracts one refund and deducts processing fees. The order data posts gross activity to the agreed sales, shipping and tax accounts, with customer payments going to a gateway clearing account. The refund produces a credit and clearing movement; the fee is recorded as an expense; the net bank receipt clears the remaining balance.
Finance reconciles the gateway settlement total to the included transaction IDs, then matches the net payout to the bank line. One order edited after settlement becomes an exception instead of being overwritten. The control passes when the clearing account reaches the expected residual and every residual item has a named cause.
Release and ownership
Run at least one full settlement cycle in a test or controlled pilot, including refund and failure paths. Obtain sign-off from ecommerce operations, finance and the integration owner. Keep the mapping register, exception procedure and close checklist with named owners. Re-test after changes to gateways, tax, order statuses, currencies or accounting apps.
Sources checked
- Xero Central: Reconcile bulk payments received from online sales
- WooCommerce: Orders Report
- Xero ZA: Accounting for ecommerce
Reviewed by
Mitrend Digital editorial team
2026-07-17
Evidence used for this page
Reviewed against current Xero online-sales reconciliation guidance and WooCommerce order reporting. Includes an original handover contract and daily control totals.
Turn the guide into a practical next step
This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.
