Ecommerce bookkeeping services that split the payout instead of banking it

Not as a single line of revenue. A Shopify Payments deposit is what is left after Shopify has taken processing fees, deducted refunds, held back anything in dispute and applied any payout adjustment. Recording that figure as sales understates your top line and deletes your fee cost entirely.

The correct treatment is to post the full gross order value to revenue, the tax collected to a liability account, the processing and app fees to expense accounts, refunds to a contra-revenue account, and the resulting net figure to a Shopify clearing account. When the deposit lands in the bank you code it against that clearing account, not against sales.

If the mapping is right the clearing account empties to near zero every month, and the small residue is timing: orders captured on the last day that pay out on the first of the next. That residue is the control. A clearing balance that grows month after month is telling you something is being double-counted or missed, and it is far easier to spot there than in a profit and loss statement six months later.

A clearing account is a balance sheet account that holds money you have earned but not yet received. It sits between the sale and the bank deposit.

One per processor matters because each processor takes its own fees, holds back money on its own terms and pays out on its own schedule. Stripe, PayPal, Amazon and Klarna each set that schedule differently, and it varies by country and account age. Amazon adds a reserve on top. Pooling them into one account destroys the only thing that makes the method useful: the ability to reconcile each clearing balance to that processor's own statement.

With separate accounts you can prove, processor by processor, that the gross recorded in your books agrees to the gross in the platform report, that fees agree, and that the closing balance equals the payouts genuinely still in transit at month-end. That is a real reconciliation. One merged account is just a guess with extra steps.

Amazon is harder in three specific ways.

First, settlement periods do not respect calendar months. A settlement period routinely spans the month end, so part of a deposit belongs to one month and part to the next, and only the settlement report can tell you which.

Second, the deduction list is long: referral fees, FBA fulfilment fees, monthly storage, long-term storage, removal orders, advertising, reimbursements, promotional rebates and returns. Each is a separate cost that tells you something, and all of them vanish if the deposit goes in as one number.

Third, Amazon holds a reserve. Money you have earned sits with Amazon rather than in your bank, which means your cash and your receivable are genuinely different figures and your books need to show both.

We take the settlement report as the source document, split it by type, post the reserve movement to the Amazon clearing account, and split any settlement that crosses the month end so each month carries its own sales.

Often, but not always, and we will tell you which before you pay for anything.

A2X-style tools take the platform settlement file and turn it into a summarised journal that already separates gross sales, fees, refunds and tax, then match that journal to the payout. For a seller on Amazon or Shopify with meaningful volume, that is the difference between an hour a month and a day a month, and it removes the transcription errors that come with manual work.

For a store doing modest order volume on one channel, the same result can be produced from the platform reports without adding a subscription, and we would rather you spent that money elsewhere.

What matters is the accounting treatment underneath, not the logo. An integration with the wrong account mapping produces wrong numbers faster. We set the mapping, check the first two months line by line against the platform reports, and only then let it run.

No. Tax collected at checkout is money you are holding on behalf of a tax authority. It belongs on the balance sheet as a liability until it is remitted.

Treating it as revenue is one of the most damaging errors we find in online sellers' books, because it inflates your top line, distorts every margin calculation built on that figure, and hides a debt that is growing quietly in the background. Sellers who do this often feel comfortable on cash and then discover they have been spending money that was never theirs.

The mechanics matter on marketplaces too: where the platform is a marketplace facilitator, it may collect and remit the tax itself, so that portion never becomes your liability and posting it as one would overstate what you owe. We separate the two treatments per channel and keep the liability account reconciled to what has actually been filed and paid.

To be plain about our limits: we do not file sales tax or VAT returns. We prepare the figures and the support so your tax professional can file from them directly.

Inventory is an asset until it sells, and the moment it sells it becomes cost of goods sold. Recording every supplier payment as an expense when it leaves the bank is what makes ecommerce profit swing wildly month to month: a big purchase order crushes a good month, and a month spent selling stock you bought in the spring looks unrealistically strong.

We hold purchases in inventory and release them to COGS as units sell, at a cost that includes what the goods actually cost to get to the customer, so landed costs such as freight, duty and import charges are part of the unit cost rather than a mystery overhead.

Where your platform or inventory tool already tracks quantities reliably, we reconcile the ledger balance to that count at month-end and post the adjustment rather than trusting either source blindly. Where it does not, we work from periodic counts and tell you plainly that the monthly figure is an estimate until the next count. Either way you get a gross margin that survives a second look.

They are timing events, and the whole point of a clearing account is to keep them from corrupting two months at once.

A refund issued in March against a January sale is deducted from a March payout. If the payout goes in net, March revenue absorbs the hit invisibly and your March margin is wrong for a reason nobody can find. We post refunds to a contra-revenue account so the reduction is visible next to the sales it relates to, and chargebacks with their fees separately, because a chargeback is a different business problem from a refund and the trend is worth watching on its own.

Where a return volume is material and predictable, a returns provision can be carried so the month that made the sale also carries its expected returns. For most small sellers that is more machinery than the decision needs, and we will say so rather than sell it. What we will not do is let a March deduction quietly rewrite January's story.

Both QuickBooks Online and Xero handle multi-currency properly once it is switched on and set up correctly, and we use that rather than converting figures by hand in a spreadsheet.

Sales are recorded in the currency they were made in and translated at the rate for the transaction date. Balances you still hold in a foreign currency, such as a Stripe balance or a Wise account, are revalued at the period-end rate, and the difference between the two is a foreign exchange gain or loss posted to its own account.

Keeping that separate matters more than it sounds: exchange movement is not trading performance, and mixing them makes a weak month look like a currency problem or hides a currency problem inside a good month. We also watch for the fee the platform charges for the conversion itself, which is a real cost and often buried in the payout.

If you sell in three currencies and pay suppliers in a fourth, we will map each one before the first close rather than discovering it halfway through.

We work in both daily and genuinely do not have a favourite. For ecommerce specifically, the practical differences are these.

Xero handles multi-currency and bank reconciliation in a way most sellers find easier to review, and its reconciliation screen makes an unmatched payout obvious. QuickBooks Online has stronger native inventory on the higher plans and is the more common choice among US accountants, which matters if your CPA wants to work in the file directly. Both connect to the main ecommerce integrations.

The decision usually comes down to two questions: what does the person who files your tax return want to see, and how many currencies are you actually operating in. We have written a longer comparison from using both across client files, and we will recommend one before onboarding rather than after.

Either way, the file structure underneath matters more than the brand: a clearing account per processor and a chart of accounts that separates fee types will make either platform useful.

Two ways to buy. Fixed monthly plans are priced on volume and complexity: Growth at $449/month suits a single-channel store with steady order volume, and Scale at $899/month suits multi-channel sellers with inventory, several processors and more than one currency. Essentials at $199/month exists for very small stores, though most sellers with inventory and more than one processor sit above it.

The alternative is a dedicated resource by the hour: $14 for a bookkeeper, $20 for a senior bookkeeper who owns the month-end close, and $28 for an ACCA-qualified accountant, with full-time equivalents at $1,650, $2,400 and $3,600 per month.

Catch-up work, such as restating a year where payouts were recorded as revenue, is quoted separately as a one-off fixed fee once we have seen the file. Every fee is agreed in writing before work starts, and we do not bill surprises.