Buying Operations Software in the Netherlands: A Straight Guide
What to ask, what to ignore, and the five things that should take us off your shortlist — written by the vendor, which is a reason to read the disqualifying list first.
A buyer's guide written by a vendor is a compromised document, so the useful thing to do with it is read the exclusions first. Ours, for the Netherlands: our invoice prints neither your VAT identification number nor your customer's, we do not check a VAT number against anything, we have no reverse-charge tax state, we have no Belastingdienst connection and no Peppol access point, and we have no Dutch payroll engine and no Dutch reference customer. If any one of those is central to your decision, you can stop here and you have saved a fortnight.
What follows is the rest of it — the questions worth asking any operations vendor selling into the Netherlands, including the ones that are awkward for us. The bias in a document like this is never in the answers; it is in which questions got asked. So the second half is the list of questions we would ask if we were the ones buying.
The five exclusions, in full
| What is missing | What that means in practice |
|---|---|
| Neither VAT number on the invoice | Yours and your customer's are both stored in the database and neither is printed on the document. The buyer's address is not printed either. For a supply to a business in another member state these are mandatory particulars, so the document would not stand up to being read carefully. |
| No VAT-number validation of any kind | The field accepts any string up to 255 characters. Nothing checks the format, the checksum or whether the number exists — including against the EU's own register. Since the zero rate on an intra-Community supply is conditional on the buyer holding a valid number, the evidence behind your zero is whatever somebody typed. |
| No reverse-charge tax state | A line can be standard, zero-rated or exempt. There is no fourth value, the last two are stored identically, and a treatment the resolver does not recognise is charged the standard rate rather than rejected. The legend can go on the document as free text, typed by hand. |
| No Belastingdienst connection, no Peppol access point | Nothing files: no btw-aangifte, no opgaaf ICP, no Digipoort, no Intrastat, and no tax dataset in the report catalog. Returns and listings are produced by your accounting system or your accountant, from exports. The Peppol half is separate and it is live rather than future — see below. |
| No Dutch payroll, no Dutch reference customer | No loonheffing, no pension administration, no submission on a pay run. And nothing on any page of ours about the Netherlands is a case study — this product was built in Nairobi and its live tax-authority integration is Kenyan. |
The one exclusion that is a problem today rather than eventually
Business-to-government invoicing in the Netherlands has been electronic since January 2019, over Peppol or Digipoort. That mandate is live now. We are not a Peppol access point and we do not connect to either network, so if Dutch public bodies are a meaningful part of your revenue you need something in the chain that can transmit — whether or not that something is us. Everything else on the list above is a gap you can work around while it is being built. This one is a door that is currently shut. The separate domestic business-to-business mandate is a proposal under the EU's ViDA reforms and was not law when this was written, so treat any vendor selling you a deadline for it with suspicion.
One thing that is genuinely not a problem here
Language. Our interface is English-only, and in the Netherlands that is close to a non-issue — a finance floor in Amsterdam, Rotterdam or Eindhoven will not be slowed down by it. This is worth stating precisely because it is a real constraint in several other markets in this corpus, and a reader comparing our pages deserves to know which is which: it is a hard blocker in Jakarta and Bangkok and a legal question in Quebec, and it is neither of those things here. What English does not solve is a statutory document in Dutch, which we do not produce. If a Dutch-language interface is a procurement requirement rather than a preference, say so early, because it is a larger piece of work than it sounds — every screen, not a document template.
Where we are a straightforward fit
Not a feature list — a shape of business. We are worth a conversation if most of these describe you.
- Your accounting package already owns your invoices and your returns, and what you are shopping for is the operations layer underneath. Then essentially none of the tax material above is your problem, and the exclusions list stops being frightening.
- Your real problem is a warehouse, or several. Goods arriving, being held, split, relabelled and sent out again — with a straight stock position across sites and a movement history you can actually follow.
- You need traceability with a date on it. Batch and expiry at item level, in both directions, held against the batch rather than reconstructed from paperwork when somebody asks on a bad day.
- Your procurement control is currently one person's attention. Requisitions, threshold approvals that refuse, purchase orders, receipts and three-way matching, without hiring a procurement department to operate them.
- You have equipment worth tracking properly — handling machinery, vehicles, chillers, racking — with a named custodian, a service history and inspection dates that are visible before they expire.
- Your sales are largely domestic and standard-rated. Then the invoice document argument above describes a problem you do not have, and our tax handling is ordinary and adequate.
Where you should rule us out
These are disqualifying rather than difficult, and we would rather write them than have you find them in month three.
| If this is true of you | Why we are the wrong choice |
|---|---|
| Most of your sales are cross-border supplies to businesses in other member states | That is the case our invoice document handles worst. Until both VAT numbers and a derived reverse-charge legend are on the printed page, you would be doing the compliance part somewhere else on the majority of your revenue. |
| You sell to Dutch public bodies | The B2G e-invoicing mandate has been live since January 2019 and we cannot transmit. This one is present rather than future. |
| You want your operations system to produce or file the VAT return or the ICP listing | It cannot, and the second one has a dependency: an ICP listing is grouped by customer VAT number, and those numbers are not on our transactions today. This is not a reporting gap that can be closed retrospectively. |
| You need Dutch payroll run inside the same system | There is no loonheffing calculation and no pension administration. Labour cost attribution to projects and cost centres exists; that is not payroll. |
| A reference customer in your own market is a procurement requirement | We do not have one. That is a fact rather than a feature, and it is a legitimate reason to choose somebody else. |
Six questions to ask every vendor, including us
None of these can be answered with a brochure
Generate an invoice PDF for a business customer in another member state, now, in front of me.
What a good answer sounds like
A document appears with both VAT numbers, the buyer's address and a reverse-charge line on it.
What a bad answer is telling you
If you are shown a settings screen instead, the question has been answered about the database rather than about the document. This is the single highest-yield question on the list and ours fails it today.
Where does the reverse-charge wording come from — the line's tax state, or a person typing?
What a good answer sounds like
Derived from the state, so it cannot be forgotten or applied where it does not belong.
What a bad answer is telling you
A free-text note is a real workaround and it is not the system knowing. Ours is a free-text note.
What does your system do with a VAT number that does not exist?
What a good answer sounds like
Rejects it, ideally by checking the EU register at the point of entry.
What a bad answer is telling you
If the answer is "we store what you type", the evidence behind your zero rate is a text box. Ours stores what you type.
How many distinct tax states can a line be saved in, and can you name them?
What a good answer sounds like
Four, named immediately, with zero-rated and exempt stored separately.
What a bad answer is telling you
If the answer is about setting a rate to zero, states are being confused with rates and the distinction will not survive being saved.
What happens if I enter a tax treatment the system does not recognise?
What a good answer sounds like
The save fails. A zero is second best, because a zero is visible.
What a bad answer is telling you
If the answer is the default rate, the system converts a careful person's attempt at precision into a plausible wrong number. Ours does this.
Which of my obligations can your software evidence, and which can it not?
What a good answer sounds like
A row-by-row answer with dates on it, including the rows that say no.
What a bad answer is telling you
A badge on a features page is not a statement about anything checkable. Ask for the scope, not the logo.
Two things worth ignoring
First, rate tables on vendor pages. The Dutch structure — a standard rate, a reduced rate and a zero rate — is stable, and what sits on each has been reopened in recent Tax Plans, with announced changes that took effect and announced changes that were dropped before they did. A vendor page printing the full assignment is telling you when it was last edited rather than what the law says. Get structures from a vendor and numbers from your accountant, and check the date on any page that offers both. We deliberately do not print the list, which is either discipline or an excuse depending on your view.
Second, data residency claimed as a setting. Ask any vendor whether EU hosting is a property of your account or of their deployment, and watch whether the answer changes shape. For us it is a property of the deployment: an EU-region deployment is a real thing we would do and price, and there is no column, flag or switch that puts one organization in a different region from its neighbours. Our compliance matrix claimed otherwise until 5 August 2026 and now says this, with the correction marked. A vendor whose answer to this question is a single word is not answering it.
What AWRA OpsHub does today
- The operational half in full — stock across locations with acknowledged transfers, batch traceability in both directions, quality holds that block picking, landed costs pushed into unit cost, procurement with approvals and three-way matching, and an asset register with named custodians.
- A per-line rate column at two decimal places on invoices, quotations and point-of-sale lines.
- Item-level tax treatment travelling with the item onto every document, and customer-level VAT exemption that is actually applied — the latter having been stored and inert until 5 August 2026.
- A free-text note that prints on the generated invoice, which is where a reverse-charge legend can go today by hand.
- Euro as an ordinary two-decimal base currency, with exchange rates recorded on the document.
- Machine-readable exports in CSV, XLSX and JSON, which is what a handoff to an accounting system or an adviser actually needs.
What it does not do
- Either VAT identification number on the invoice, and the buyer's address with them. All three stored, none printed.
- A reverse-charge treatment, and a validation failure for unrecognised treatments — today they silently produce the organization's default rate.
- A stored distinction between zero-rated and exempt. Both collapse to the same nil.
- Any VAT-number validation, including against the EU register.
- A per-rate split on the printed document. A mixed invoice shows one blended label and one total.
- Any Belastingdienst integration or return output, and no Peppol access point for business-to-government invoicing.
- A Dutch payroll engine — no loonheffing, no pension administration, no submission on a pay run.
Not ours, by choice
- We will not tell you whether a supply is reverse-charged, zero-rated or exempt. Those are determinations about your business that your adviser makes and signs, and a vendor with a view on them is inviting reliance it cannot carry.
- We will not be your filing agent, even once an integration exists. The obligation is yours and software should make it answerable rather than absorb it.
- We will not claim per-organization data residency, because it does not exist. Hosting region is a property of a deployment. An EU-region deployment is real and priceable; it is not a setting.
The Dutch list has an obvious order and the first item is far smaller than the rest: put both VAT identification numbers and the buyer's address on the printed document, which is a template and a query rather than a schema change because the data is already stored. Then a reverse-charge treatment that survives being saved, with the legend printed from it and a validation failure for values the resolver does not know. Then validation of a counterparty number against the EU register. Then a return and an ICP listing assembled from the result, and a Peppol access point for the government side. Every one of those improves every EU market in the product rather than only this one, which is the argument for doing it properly rather than for the Netherlands. The precedent that we finish market-specific work of this kind is Kenya: a live tax-authority integration and a maintained statutory payroll engine, both ours. A written specification, a timeline and a price agreed before anything starts, and no dates on a public page.
Worth stating rather than leaving to be inferred. Nothing above says our arithmetic is wrong — the totals are right and the per-line rates are stored correctly. The failure is specific to the cross-border document, and the reason it dominates a buyer's guide for this country is that here the cross-border invoice is the ordinary invoice rather than the exception. For a domestic, standard-rated Dutch business, most of this page describes a problem you do not have.
What is not built for the Netherlands today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in the Netherlands. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If the buyer's number on the document, and something that checks it is real, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Four builds, and the first one is far smaller than the three behind it
Put the particulars on the printed invoice. Your VAT identification number, your customer's, and their address are all stored today and none of the three reaches the document — so the first build is a template and a query rather than a schema change, and it removes most of the reason a Dutch cross-border invoice would fail on inspection. Then a reverse-charge treatment that survives being saved, with the legend printed from the line's own state instead of typed into a notes box by hand, and a validation failure for treatments the resolver does not recognise rather than the silent fall-through to the standard rate it does today. Then validation of a counterparty VAT number at the point it is entered, against VIES, because the zero rate on an intra-Community supply is conditional on that number being valid and we currently accept any string. Only then a btw-aangifte and an opgaaf ICP assembled from the result — quoted last because an ICP listing is a per-customer total keyed to VAT numbers, and it cannot be built until those numbers are on the transactions in a form a query can read. A Peppol access point for business-to-government invoicing is a separate build and a present one, since that mandate has been live since January 2019.
Banks and payments
SEPA credit transfers and direct debits, iDEAL collection, and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents that authorised it rather than being re-keyed from a bank screen.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Dutch payroll engine with loonheffing computed on live employee records, pension administration and submission on each pay run. None of it exists today; labour cost attribution to projects and cost centres does.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe one-line version
If your tax lives somewhere else and your problem is a warehouse, this is a short and straightforward conversation. If you want your operations system to produce lawful cross-border invoices and file Dutch returns, it is the wrong system today — and the five exclusions at the top of this page are the fastest way to establish that without spending a fortnight on it.
Bring one of your own invoices
The fastest way to find out whether we fit is to show us a real cross-border document and let us tell you exactly what our template would and would not have printed on it. We published our own failures first, which is the only thing that makes it fair to ask anybody else for theirs.
Read the Netherlands page