Stop re-typing your orders into your accounting software

Your books do not need every line of every order. They need revenue by period, tax collected by jurisdiction, payment processor fees, refunds and shipping income, in a shape your accountant can reconcile against bank deposits. Some businesses genuinely need per-order invoices — B2B with purchase orders, anywhere invoices are a legal document — and others are far better served by a daily or weekly summary journal. Deciding this before choosing a tool prevents the most common failure: an integration that floods the ledger with thousands of unreconcilable entries.

• Revenue by period, in the currency you file in
• Tax collected, split by jurisdiction
• Processor fees as their own expense line
• Refunds and shipping income kept distinct from product revenue

A payment processor does not deposit each order individually. It deposits batches, net of fees, on its own schedule. So an accounting system fed one entry per order will never match the bank feed, and someone will spend every month explaining the difference. The workable pattern is to record sales as they occur, record the payout as a separate transaction, and reconcile the two through a clearing account — with processor fees booked as an expense. Netting them off revenue hides them. Get this structure right at the start and monthly close stops being an argument.

US sales tax varies by state, by product category and by economic nexus thresholds — commonly $100,000 in sales into a state, sometimes a transaction count — that you can cross without noticing. Manual handling of this is where small stores create real liabilities. Tax calculation belongs in a service that keeps current rates, such as TaxJar or Avalara, and what flows into accounting should be the tax actually collected, broken down enough to file. This page is general information and not tax advice: the rates and your obligations are a question for an accountant, and the integration's job is to make their answer easy to act on.

This is where most integrations quietly break. A partial refund on a multi-item order has to reduce the right revenue line, adjust the tax proportionally and account for a processing fee that may or may not be returned depending on your processor. Test these cases specifically before trusting any sync: full refund, partial refund, refund crossing a month boundary, and a refund on an order that included discounted shipping. If those four are handled correctly, the rest usually is too.

Cost of goods sold and stock valuation are related to but distinct from order sync, and conflating them is a common design mistake. If your accounting system holds inventory value, decide which system is the source of truth for stock quantities before connecting anything — two systems each convinced they own stock levels will produce a slow, confusing divergence that surfaces as an oversell. Inventory sync across channels covers that problem properly.

Three routes. A connector plugin is fastest to deploy and enough when one store feeds one ledger. Middleware earns its subscription once an ERP or a second channel needs the same mapping rules; its error visibility is what a plugin lacks. A custom integration on the WooCommerce REST API is right for genuinely unusual rules and the worst option otherwise: you own the retry logic. Whichever you choose, ask what happens when the accounting system is down, whether failed syncs are retried and visible, and whether a silently failed day can be replayed without duplicates.

Below roughly a hundred orders a month, a monthly export and a bookkeeper is cheaper and less fragile than any integration, and when it fails it does so where somebody can see it. Automate when the hours become material, when the error rate starts costing more than the tool, or when tax complexity has outgrown a spreadsheet. Automating earlier than that usually buys you a subscription and a new category of problem to debug.