Do you sell on bol, the largest marketplace in the Netherlands and Belgium, and run your accounting in AFAS or Exact Online? Then someone in your company probably retypes orders, books the bol settlement by hand, or spends the end of the month working out why the balance doesn't match. An integration fixes that, but only if you make a few choices first. This article covers which data has to move, which choices those are, and where it usually goes wrong in practice.
What actually needs to be connected?
"Connecting bol to AFAS" sounds like one integration, but in practice it is five, each with its own direction and rhythm:
- Orders: from bol to AFAS or Exact, so the sale, the stock movement and later the revenue are in your books.
- Stock and offers: from your system to bol, so you never sell more than you have. If you also sell through your own webshop or other marketplaces, stock has to be right on every channel.
- Shipping: track-and-trace back to bol, on time, or bol sees the order as shipped late.
- Returns and cancellations: back into your books as credits and stock corrections.
- The financial settlement: what bol pays out, which commission and fees are deducted, and how that matches your bank.
The first four are logistics and automate well through bol's Retailer API. The fifth is accounting, and in our experience that's where most of the work and most of the errors are.
First decide: which system leads?
Before a line of code is written, it has to be clear for each type of data which system holds the truth. Otherwise systems overwrite each other and nobody knows which price or stock level is right.
- Products and EAN codes: usually led by AFAS or Exact. Bol uses the EAN as its key, so every product you sell on bol needs the same EAN in your administration.
- Stock: led by your stock system. That can be AFAS or Exact, but also a separate WMS. What matters is that there is only one source.
- Selling prices on bol: often deliberately separate from your other prices, because commission differs per category. Decide whether those prices live in AFAS or Exact, or only in bol or a pricing tool.
- Orders: led by bol until they ship; after that by your administration.
How do you book the orders?
A bol order has to land somewhere in your books. The main choice is which customer account (debtor) you book it on:
- One collective debtor "bol": all orders on a single debtor, with the bol order number as reference. Simple, and it matches how the money comes in: through bol. You also don't store customer data you don't need.
- A debtor per customer: only useful if you really need customer data, for example for business customers who want an invoice in their name. Keep in mind that you then store personal data, with the GDPR duties that come with it.
Which option fits depends on your VAT situation, your reporting and what your accountant wants. Put the choice to your accountant up front. Changing it afterwards takes far more time.
The bol settlement: the hardest step
The customer pays bol. Bol pays you the sales amount periodically, minus commission and other fees, and sends you an invoice with a specification for those. So one net amount arrives in your bank account, made up of hundreds of orders, returns and fees.
The mistake we see most: booking only that net amount as revenue. Your revenue is then wrong, and you lose sight of what bol costs you. The clean way:
- Book revenue gross, per order or per period, as the customer paid it.
- Book bol's commission and fees as a cost, based on bol's invoice.
- Match the payout against the open items on the collective debtor, so the bank line reconciles exactly.
That matching is where a good integration saves time: work out automatically which orders, returns and fees each payout contains, and only show the differences to a person. More on this under reconciliation.
VAT: the Netherlands and Belgium
Bol sells to customers in the Netherlands and Belgium. If you sell from the Netherlands to Belgian consumers above the EU distance-selling threshold, you charge Belgian VAT, usually declared through the OSS scheme. Your integration therefore has to know per order which country the customer is in and pick the right VAT code. Belgian business customers with a valid VAT number get an invoice without VAT, as an intra-community supply. Design for those cases up front, not when the first customer asks.
Own shipping or Logistics via bol?
If you ship yourself, orders come to you, your warehouse handles them and the integration sends track-and-trace back to bol. With Logistics via bol (LVB, bol's fulfilment service), part of your stock sits in bol's warehouse and bol ships the orders and handles the returns itself.
For the integration, LVB means: set up stock at bol as a separate warehouse location in AFAS or Exact, book deliveries to bol as a stock transfer, not a sale, and pull sales and returns from bol to update that location. Otherwise your books think you have stock that has long since reached a customer.
Standard connector, integration platform or custom?
There are three routes, and the cheapest is not always the best:
- A standard connector from the AFAS or Exact app store, or from a specialised supplier. Quick to go live, and a good fit if your processes are close to the standard one: one channel, own shipping, simple VAT.
- An integration platform (iPaaS) where you configure flows between systems. Useful if you connect many systems and have someone in-house to manage it. Complex rules, such as matching payouts, get hard to follow in it quickly.
- Custom, through the APIs of bol and AFAS or Exact Online. Worth it with high volumes, several channels, LVB next to own shipping, or non-standard booking rules. You then decide yourself how errors show up and what happens when a system is briefly unavailable.
Start with the standard connector if it covers your process. When you notice staff working around it with Excel and manual corrections, that's the moment to look at custom.
Pitfalls we see in practice
- Duplicate orders: when the integration fetches again after an outage, the same order must not end up in AFAS or Exact twice. Always check the bol order number before booking.
- Partial shipments and cancellations: an order with three lines can ship in parts or be partly cancelled. Work per order line, not per order.
- Asynchronous processing at bol: many actions, such as confirming a shipment, are queued at bol. The integration has to check that the action really succeeded, or you think something shipped while bol never accepted it.
- API limits: bol, AFAS and Exact Online all limit how many requests you can make per period. Build the integration so it waits calmly and continues later, instead of losing data.
- Rounding: amounts per line and per order can differ by a cent between systems. Agree where you round, or the payout never reconciles exactly.
- No visibility of errors: an integration that fails silently is worse than none. Make sure there is an overview of failed messages and an alert when something gets stuck.
Checklist before you start
- For each type of data (products, stock, prices, orders), it's decided which system leads.
- Every bol product has the same EAN in AFAS or Exact.
- Agreed with your accountant: collective debtor or debtor per customer, and how revenue, commission and payouts are booked.
- VAT codes for the Netherlands, Belgium and intra-community supplies ready in your administration.
- With LVB: a separate warehouse location for the stock at bol.
- Agreed who sees and fixes integration errors, and how fast.
Not sure which route fits, or is an existing integration stuck on the settlement or the matching? We're happy to take a look. See also our pages on bol integration, multi-channel selling and inventory sync, or get in touch.