Marketplace Orders That Post Themselves to the GL

Sell something online and the accounting should already be done. That's not how most ERPs work. There, e-commerce is a separate world — a storefront here, a marketplace there, and a tangle of middleware and nightly sync jobs in between trying to keep them agreeing with the general ledger. LedgerQ takes the opposite stance: online orders flow straight through to posted accounting, with no integration layer to babysit.

In summary: LedgerQ treats an online sale as one continuous flow — order becomes a sales order and invoice, the sale posts to the ledger, and when the marketplace releases the payout, LedgerQ reconciles it per order. For Shopee specifically it reads each order's escrow breakdown and books a balanced journal — net to bank, platform fee, payment fee, withholding tax, and subsidy — so the cash you actually receive ties back to the books with nothing stranded in a clearing account.

Why is marketplace accounting so painful in most systems?

The trouble starts with a structural gap: in most stacks, the storefront and the ledger are two different products. An order placed on the marketplace lives in one system; the accounting lives in another; and a middleware layer shuttles data between them on a schedule. That arrangement creates three recurring problems.

First, latency — a sync job that runs at 2 a.m. means your books are, by design, hours behind reality, and when it fails silently, they're behind by days and nobody notices until the numbers don't add up. Second, drift — a mapping layer between two systems is a translation, and translations rot: a new fee type the marketplace introduces, a tax rule that changed on one side but not the other, an order status that doesn't quite map. Third, and most damaging, the payout doesn't match the order. Marketplaces don't pay you what the order said; they pay net of fees, withholding tax, and subsidies. If you only book the gross sale and drop the payout into the bank, your ledger and your cash never agree — and the gap is made of exactly the things you most need to track.

What makes it one system instead of two bolted together?

LedgerQ ships with a native, integrated e-commerce storefront — not a third-party plugin grafted onto the side — alongside a live Shopee integration. The distinction matters more than it sounds. When the storefront is part of the platform, an order doesn't have to be imported; it's already inside the system that does your accounting.

So a customer checks out and the order automatically becomes a sales order and invoice in the ERP. Inventory updates in real time across both the storefront and the back office — the same stock figure the warehouse sees is the one shoppers see. Customer records live in one place, so there's no sync drift, no duplicate profiles, no reconciling "the website's view" against "the ledger's view." And because it's all one system, e-commerce revenue shows up natively in financial reporting — it doesn't arrive as a foreign feed you have to map. Tax is the tell: online sales run on the same tax rules as the accounting module, not a separate plugin's idea of what tax should be. One rulebook, applied everywhere.

Orders to sales orders to journal entries — one flow

The thing other ERPs treat as three integration problems, LedgerQ treats as one continuous motion:

Order → sales order & invoice → journal entry.

There's no handoff where data leaves one product and is re-keyed into another, and no overnight batch where today's sales finally catch up tomorrow morning. On Shopee, a buyer's order arrives by webhook and becomes a sales order and invoice, and the sale posts to the ledger — with a scheduled catch-up poller that re-pulls recently updated orders so a missed webhook doesn't quietly drop an order. The order that posts at checkout is the order your books reflect.

How does per-order escrow reconciliation work?

This is the path that solves the problem that quietly breaks naïve marketplace accounting: you don't get paid what the order said. Shopee holds each order's proceeds in escrow and, when it releases, pays out net of platform fees, payment fees, withholding tax, and any shipping subsidy or voucher.

LedgerQ reconciles this per order — not from a monthly statement, but from each order's own escrow release. When Shopee releases escrow, LedgerQ reads that order's income breakdown and books a single balanced journal for it: the net that hit your bank, the platform fee, the payment fee, the tax withheld, the shipping subsidy, and the clearing offset. Each component lands on the correct side of the correct account, and posting fails loudly if a fee is present but its GL account is unmapped, so nothing silently misposts.

A worked example (illustrative figures, not real data). A ₱1,000 order does not arrive as ₱1,000 in the bank. Shopee's escrow release for that one order might look like:

• Gross order value: ₱1,000
• Platform fee: −₱60
• Payment fee: −₱20
• Withholding tax: −₱10
• Shipping subsidy added: +₱25
• Net paid to bank: ₱935

The invoice recognized ₱1,000 of revenue when the order was placed. The escrow settlement then books the ₱60 platform fee and ₱20 payment fee as expense, the ₱25 subsidy as income, the ₱10 as a creditable withholding-tax asset (recoverable at filing, via BIR Forms 2306/2307 — not buried in fees), and ₱935 to the bank clearing account. Add it up and the journal balances against the ₱1,000 already on the books. Nothing is left floating for someone to chase down at month-end. Those entries reach the general ledger automatically.

Why does treating withholding as an asset, not a cost, matter?

That ₱10 in the example is easy to get wrong. A generic connector books it as just another fee — a cost that disappears into your expenses. But Philippine expanded withholding tax on marketplace payouts is creditable: it's tax paid on your behalf that you reclaim when you file. Booking it as an expense understates your recoverable assets and overstates your costs. LedgerQ routes it to a dedicated creditable-withholding-tax asset account, so it stays visible and recoverable. That's the kind of Philippine-specific detail that separates a real integration from a generic one — and it's covered in depth in our Shopee seller accounting guide.

Why does "no integration layer" matter?

It's tempting to treat "no middleware" as a convenience — one less tool, one less subscription. It's more than that. Every integration layer is a place where two systems can disagree, and every disagreement is somewhere reconciliation has to happen by hand.

Because LedgerQ's storefront, Shopee connector, inventory, tax engine, and general ledger are one system, those seams don't exist. There's nothing to sync because nothing is separate. Revenue is current because it was never in a different place. Escrow components are accounted for because reconciling each order's payout is part of the platform, not a spreadsheet ritual. The books reflect what happened online not because a job ran on schedule, but because there was never a gap to close.

Two honest caveats worth stating plainly: LedgerQ's live marketplace reconciliation currently covers Shopee (not Lazada or TikTok Shop), and it reconciles per order from escrow releases — not by matching a consolidated marketplace statement. That per-order approach is deliberate: it ties each payout to the exact order that produced it, which is what makes the cash reconcile to the peso.

Frequently asked questions

Does LedgerQ reconcile Shopee payouts from a monthly statement or per order? Per order. When Shopee releases an order's escrow, LedgerQ reads that order's income breakdown and books one balanced journal for it — net to bank, platform fee, payment fee, withholding, and subsidy. Tying each payout to its own order is what lets the cash reconcile to the peso rather than to a bulk statement total.

What happens to the withholding tax Shopee deducts? It's booked to a dedicated creditable-withholding-tax asset account, because Philippine expanded withholding on marketplace payouts is recoverable at filing (via BIR Forms 2306/2307). LedgerQ keeps it visible as an asset rather than losing it in fees, so you can actually claim it back.

What if a Shopee order webhook is missed? A scheduled catch-up poller re-pulls recently updated orders, so an order that didn't arrive by webhook is still picked up and posted. Missed webhooks are caught by reconciliation rather than silently dropped.

Which marketplaces does LedgerQ reconcile today? Shopee is the live, escrow-reconciled integration. Lazada and TikTok Shop are not covered by the same automated escrow reconciliation, so if you sell across several marketplaces, confirm current coverage before you rely on it.

What stops a fee from being posted to the wrong account? Fee-to-GL mapping is configurable per channel, and posting fails loudly if a fee type is present in the escrow breakdown but has no mapped account. That means an unmapped fee raises an error instead of silently landing in the wrong place or being dropped.