Connect Commercetools with Fortnox to sync orders, customers, and VAT-ready invoices automatically, keeping your bookkeeping accurate and your month-end close faster.
• Order, customer, and payment events are read from Commercetools APIs and transformed into Fortnox entities such as customers, invoices, voucher rows, and payments, depending on your bookkeeping model.
• Identifiers are mapped between systems (order number, customer ID, invoice number, payment reference) to support traceability and consistent updates on retries.
• Delta-based sync logic processes only changed orders and related events (captures, refunds, cancellations), with idempotent handling to avoid duplicate Fortnox records.
• Tax, shipping, discounts, and line items are mapped to Fortnox accounts, VAT codes, and dimensions, with rounding and currency rules applied per store configuration.
• Status ownership is separated: commerce status remains in Commercetools, while accounting document states (invoice posted, payment booked) are retrieved from Fortnox when needed.
• Error handling logs rejected payloads, validation failures, and API rate-limit responses, and routes them to a retry queue with correlation IDs for debugging.
.png)
We map Commercetools orders, captures, refunds, and VAT rules to Fortnox customers, invoices, and voucher-ready records via APIs. The result is consistent bookkeeping data without manual exports.
Typical sync covers customers, orders, payments, invoices, credit notes, shipping, discounts, and VAT breakdowns. We also handle edge cases like partial shipments, cancellations, and mixed payment states.
Yes, as long as the tax logic is defined per store and mapped to the right Fortnox settings and accounts. We usually implement store-level configuration so finance can reconcile per entity and market.
We use event-driven updates and idempotent syncing so edits, refunds, and credit notes don’t create duplicates. This keeps Fortnox aligned with the final paid state, not the first version of the order.
Timeline depends on the accounting rules, payment providers, and required Fortnox objects, but most projects follow a clear build, QA, and go-live path. Upfront mapping workshops reduce rework later.














