As order volume grows in a WooCommerce store, accounting splits in two: the orders on the site, and the records typed into the accounting program by hand. At month-end the two are supposed to match. In most businesses they do not, and someone spends hours hunting the difference.
An accounting integration removes that split. But “pushing an order into the program” is not as simple as it sounds: without correct customer matching, stock cards, VAT rates and refund handling, the integration produces a pile of records that get corrected manually anyway.
Which program, and how does it connect?
| Program | Connection route | Typical use |
|---|---|---|
| Paraşüt | Cloud API | SMEs and e-commerce; the quickest group to set up |
| Logo | Its own integration interface or an intermediate database | On-premise, multi-user setups |
| Mikro | Its own integration interface or an intermediate database | Dealer and wholesale-heavy businesses |
| Your own ERP | Custom development | Businesses with distinctive rules |
What matters is not the brand but whether the program exposes an interface. On-premise programs are usually reached through a service running on the server; cloud programs are reached directly through an API. For the technical detail see Logo API integration and Mikro API integration.
Four decisions to make before building
1. Customer record logic
Creating a separate customer record for every order means thousands of useless records within months. The healthy approach: group consumer sales under a single retail account and open tax-number-based records for business buyers. Define a matching rule on e-mail or tax number to prevent duplicates.
2. Stock cards and SKUs
The product in the store and the stock card in accounting must carry the same code. If codes differ, the integration falls back to matching by name and the smallest spelling difference posts to the wrong card. If stock is tracked in accounting, decide up front which system holds the truth.
3. VAT rates
Per-product VAT must be identical in both systems and fed from one source. Managed separately, the two inevitably drift apart — which means wrong invoice totals and correction work.
4. The moment of invoicing
Is the invoice issued at order, at payment confirmation, or at dispatch? Invoicing unpaid orders means correction documents when they are cancelled. Pick one rule and apply it on every channel.
Refunds, partial refunds and shipping
- Full refund: a refund invoice or correction document is created and stock returns.
- Partial refund: only the refunded lines are processed.
- Shipping fee: whether it is refunded must be a rule, not a case-by-case decision.
- Loss or damage: accounting-wise this differs from a refund and needs its own line.
How do you know the integration is healthy?
- Reconciliation: store revenue and the accounting sales total match at month-end without manual fixes.
- Error visibility: orders that fail to transfer appear on a list; nothing disappears quietly.
- No duplicates: the same order is never transferred twice; every record has a unique identifier.
If these three do not hold, the integration may look alive while doing nothing to reduce manual work.
What drives time and cost?
A standard WooCommerce store connected to a cloud accounting program is a matter of days. What extends it: multiple warehouses, marketplace orders joining the same flow (see marketplace integration), custom pricing and discount rules, migrating historical data, and connecting to an on-premise program.
If you are considering your own pre-accounting platform, see Muhasebecio; for build support, our e-commerce integration service.
Summary
The quality of an accounting integration shows up at month-end reconciliation. Write down the rules for customer matching, stock cards, VAT and refunds; the technical connection is the easy part after that. See our WooCommerce integration guide or review your setup with us.