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 rather than quietly netted off revenue. 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 you may cross without noticing. Manual handling of this is where small stores create real liabilities. Tax calculation belongs in a service that keeps current rates, and what flows into accounting should be the tax actually collected, broken down enough to file. This page is general information rather than 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.

Practically, there are three routes. A dedicated connector plugin is fastest to deploy and adequate for standard needs. A middleware service handles multiple systems and mapping rules with better error visibility. A custom integration on the WooCommerce REST API is the right answer only when your rules are genuinely unusual. Whichever you choose, the questions to ask are the same: what happens when the accounting system is down, are failed syncs retried and visible, and can you replay a day that failed silently without creating duplicates.

Below roughly a hundred orders a month, a monthly export and a bookkeeper is cheaper and less fragile than any integration, and it fails in obvious ways rather than silent ones. 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.