An accounting integration turns orders, invoices, and payments from your online store, portal, or planning system into entries in your accounting software automatically. Whether those entries are right depends on rules you agree on up front: which ledger account, which journal, which VAT code, which customer or supplier, and which period. Your controller or accountant sets those rules, and the integration applies them the same way every time.
Below you'll read where accounting integrations go wrong in practice and how to set up each part, from the chart of accounts to the month-end reconciliation. We use four packages that are common in the Netherlands as examples: Exact Online, AFAS Profit, Twinfield, and SnelStart. Each offers an API for posting entries, and their rules below come from public documentation.
Where an accounting integration goes wrong
Teams connecting a store or custom application to the accounting package focus on the technical part first: authenticate, send an invoice, get a confirmation. That part usually works quickly. The trouble comes later, at the first VAT return or month-end close.
Manual work in finance is error-prone, and that's the work an integration should remove. In a Gartner survey of 497 people in the controllership function, 18% said they make a financial error at least daily, 33% several per week, and 59% several per month. An integration takes the retyping away. A badly configured one repeats the same mistake on every order, and nobody sees it happen.
Most errors fall into a handful of groups:
- Revenue or costs on the wrong ledger account, because a new product or payment method has no mapping.
- A wrong or missing VAT code, so the VAT return doesn't match revenue.
- Duplicate customers, because the store sends every order as a new customer.
- Entries dated in a period that's already closed, or entries rejected for that reason.
- Payments that aren't matched to invoices and stay open as receivables.
This article covers the accounting side. For the broader question of connecting your store, WMS, and planning to an ERP, including connectors and middleware, read our article on ERP integration. How an API works technically is explained in what is an API integration.
Mapping ledger accounts: the controller decides, the integration follows
The chart of accounts belongs to finance. The integration reads it and adds nothing of its own. So you record in a mapping table which event in the source lands on which account, in which journal, and with which VAT code. The controller or accountant fills in the table, and the developers build what it says.
A simplified example for an online store with a payment provider:
| Event in the source | Journal | Ledger account | VAT code | Relation |
|---|---|---|---|---|
| Invoice, standard rate product | Sales journal | Revenue, standard rate | Standard rate | Customer |
| Invoice, reduced rate product | Sales journal | Revenue, reduced rate | Reduced rate | Customer |
| Return or credit note | Sales journal | Same revenue account as the invoice | Same code as the invoice | Same customer |
| Payment provider payout | Bank journal | Payment provider clearing account | None | None |
| Payment provider fees | Purchase or general journal | Payment costs | Set by the accountant | Payment provider as supplier |
| Subcontractor invoice from planning | Purchase journal | Cost account per type of work | Set by the accountant | Supplier |
The names are examples. The accounts and codes you use follow from your own chart of accounts and your accountant's choices. Three rules keep a table like this manageable:
- Mapping as configuration. Store the table outside the program code, so finance can change an account without a new release.
- Stop on unknown. Let the integration hold back an entry with a clear message as soon as a combination is missing. A catch-all "to be classified" account fills up without anyone noticing.
- Read codes through the API. Fetch accounts, journals, and VAT codes from the package and validate the mapping against them. Exact Online, for example, exposes GLAccounts, Journals, and VATCodes as resources in its REST API.
Journals and VAT codes in an accounting integration
A journal sets the type of entry: sales, purchases, bank, or general. Where possible, give the integration its own sales journal or number range. Finance then sees which entries arrived automatically and can reverse a faulty batch without touching manual entries. Whether a separate journal fits your books is the controller's call.
VAT needs extra care. The Netherlands, to take one example, has a standard rate of 21%, a reduced rate of 9%, a zero rate, and exemptions, as the Dutch tax authority Belastingdienst explains. On top of that come cases like reverse charge and cross-border supplies, each with its own code in the package. Other countries have their own rates and codes, and the principle is the same. The integration should send a VAT code with every line. Deriving the rate from the difference between gross and net amounts breaks on discounts and rounding.
Don't count on the accounting package to reject a wrong code. The documentation for AFAS Profit states that it doesn't check whether VAT codes are valid when journal entries come in through its API. The check belongs in the integration or the mapping table. To pick the right code, the integration also needs data from the source, such as the customer's country and VAT number. Which code fits which situation is up to the accountant.
Customers, suppliers, and accounting periods
Every sales entry is tied to a customer and every purchase entry to a supplier. The first trap is duplicate relations. A store often knows a customer only by email address, so without a stable key the integration creates a new customer for every order. Store the relation number from the accounting package in the source application, or match on a stable identifier such as a company registration number or VAT number. Matching on names produces two records for one customer sooner or later.
For consumers, many organizations use one collective customer account. That's finance's choice, and the integration should handle both. Suppliers raise another issue. Don't let the integration overwrite the bank account number of an existing supplier without review. A changed account number should pass a person first.
The second trap is the period. In AFAS, the entry date sets the financial year and period automatically, and posting into a blocked period isn't allowed, according to the UpdateConnector documentation. Agree which date the integration uses as the entry date: invoice date, delivery date, or payment date. Also decide what happens to an invoice that arrives after finance has closed the month. The integration queues the entry and flags it. Finance decides whether it goes into the next open period.
Rounding, credit notes, and payment matching
A one-cent rounding difference looks small, yet it keeps a reconciliation open. In the Netherlands, the Belastingdienst allows two methods: round the VAT amount per invoice line or on the invoice total. Using both side by side isn't allowed. If the store rounds per line and the accounting package calculates on the total, cent differences appear. The fix is simple: the integration sends the VAT amount exactly as it appears on the invoice, and finance names an account for any remaining rounding differences.
Post credit notes as documents of their own, with a reference to the original invoice, on the same account and with the same VAT code. An integration that handles a return by editing the original entry wipes out the audit trail.
Payments are the third source of open items. A payment provider often pays out one net amount for dozens of orders, with its fees already deducted. Post the payout through a clearing account, post the fees separately, and match each order on its invoice number. If the clearing account isn't zero at the end of the day, an order, a fee, or a refund is missing.
Control and reconciliation afterwards
An accounting integration is only finished when finance can check what it did. Four checks belong in every build:
- Revenue per day. The total per VAT code in the source application equals the total in the sales journal.
- Clearing accounts. The payment provider clearing account and any suspense accounts are zero after processing.
- Open items. Open receivables in the package match unpaid invoices in the source.
- Trail per entry. Every entry carries the order or invoice number from the source. If the same order arrives twice, one entry results.
That trail has a long life. In the Netherlands, the Belastingdienst requires businesses to keep their records for 7 years and explicitly names the general ledger and the receivables and payables records. How long you keep the integration's logs is something to agree with your accountant.
Plan for the package's limits too. AFAS accepts at most 1,000 lines per journal entry. Twinfield rejects transactions above 1,000 lines, recommends no more than 500, and allows 10 concurrent requests per client and organisation. A daily summary entry for a busy store has to be split up. SnelStart's documentation lives on its B2B API portal.
We build accounting integrations as part of our software integration and API development work. We do that with 30+ engineers in Nijmegen and Sarajevo, more than 30 years of experience, and 100+ projects, certified to ISO 9001 and ISO 27001. We start with the mapping table together with your controller, and the people who build the integration keep it running afterwards. If you're planning one, talk to us.
Frequently asked questions
What is an accounting integration?
An accounting integration is software that turns data from an online store, portal, planning system, or custom application into entries in accounting software such as Exact Online, AFAS, Twinfield, or SnelStart. It picks the journal, ledger account, VAT code, relation, and period for each entry by rules agreed in advance.
Who decides the ledger accounts and VAT codes in an integration?
The controller or accountant. They record in a mapping table which event lands on which account, in which journal, and with which VAT code. The developers build the integration to follow that table and make sure it stops with a message when a combination is missing.
Should you post each order separately or as a summary entry?
That depends on volume and on what finance wants to trace. Separate entries make matching easy. A daily summary entry saves lines, but watch the package's limits, such as 1,000 lines per journal entry in AFAS and per transaction in Twinfield.
What happens to an entry dated in a closed period?
The accounting package usually rejects it. A good integration queues the entry, flags it, and posts it once finance has chosen an open period.
