The sentence people reach for is that e-invoicing "changes VAT compliance". It does not. Every rule about where a supply takes place, who is liable and which category applies is exactly where it was, in the VAT Directive and in the national law that implements it.
What changes is the deadline. A determination that used to be settled at some point between raising the document and filing the return now has to be settled before the document leaves your system, because the document has fields that will not accept an unresolved answer, and because in a clearance regime the administration sees it at the same moment your customer does.
That is a scheduling change, and scheduling changes are the ones that break organisations. The work was always there. It was being done late, by people who had the whole period to notice, and it is now being done at the instant of issue by a system that will not ask for help.
Determination as an ordered sequence
Treat it as a sequence rather than a lookup, because each answer narrows the next question. The order matters: getting the place of supply wrong makes every subsequent step irrelevant.
- What is being supplied — goods or services, and which kind, since the place-of-supply rules differ
- Where the supply takes place under those rules, which is not always where anything physically moved
- Who the customer is: a taxable person acting as such, a non-taxable legal person, or a private individual
- Whether the customer's status is evidenced rather than assumed, and what the evidence is
- Whether liability shifts to the customer, and on what basis it shifts
- Which category the supply falls into: standard rate, reduced rate, zero rate, exempt, outside scope, or reverse charge
- Which rate applies in the Member State of supply, and for which of your line items
- What the document must carry as a consequence: the category code, the rate, and where the rate is nil, a reason
Nothing in that list is new. What is new is that the last step used to be prose and is now a set of coded fields that a validator will check for internal consistency.
Every step is a master data question
Read the sequence again and notice that a system answers almost none of it from the transaction. It answers from the customer record, the item record and your own registration data. The transaction supplies quantities and prices; the determination comes from master data that somebody maintained, or did not.
| Question | Record that answers it | Consequence when it is empty or wrong |
|---|---|---|
| What is being supplied | Item master: type, tax classification | The system applies a default classification and the rate is wrong on every line of that product |
| Where the supply takes place | Customer address, delivery address, item type | Determination runs against the wrong country, so the rate is correct for a jurisdiction that is not involved |
| Customer status | Customer master: tax registration, scheme | Customer is treated as a private individual and charged domestic VAT that should have been reverse-charged |
| Whether the registration is valid | Verification evidence held against the customer | The registration is present, invalid, and used anyway; the exemption fails on assessment, not on issue |
| Whether liability shifts | Customer status plus supply type | The document charges tax the customer will not pay and will not accept |
| Which category applies | Tax code configuration | The wrong tax category code is emitted; the receiver's validation rejects, or worse, accepts |
| Which rate applies | Rate table by country and item classification | A stale rate survives a rate change and is invisible until reconciliation |
That last row is the point of the table. Determination errors are not random. They are systematic, because they come from a record that is wrong in the same way every time it is used. One bad customer classification does not produce one bad invoice; it produces every invoice to that customer for as long as nobody looks. The master data work that nobody puts in the business case is determination work wearing a different hat.
What the document has to say, and what it has to say it with
The semantic model gives determination somewhere to live. Each line carries a tax category, the document carries a breakdown per category and rate, and where the rate is nil there has to be a stated reason. The business terms and groups that hold this are stable identifiers, and the values they take are code list entries rather than free text — which is what makes automated checking possible and what makes a plausible-looking wrong answer fail.
Two constraints follow, and both surprise people.
The first is that consistency is validated even when correctness cannot be. A validator cannot know whether your customer is genuinely established abroad. It can know that a document claiming a shifted liability while carrying a domestic rate is contradicting itself, and it will refuse that document. Most determination rejections are of this kind: the treatment is defensible and the way it has been expressed is not.
The second is that the values come from maintained code lists rather than from your own vocabulary. A category your finance team calls "zero-rated export" has to be mapped to something the list contains. That mapping is a design decision, it is usually made once by somebody in a hurry, and it is almost never revisited when the business starts doing something new.
Where a determination input is missing, a system does not stop. It falls back — usually to the domestic standard rate, occasionally to whatever the last transaction used. Neither produces an error message. A completeness report showing 98 per cent of customers with a tax registration is describing the 2 per cent that will be silently mistreated on every document until somebody reconciles the output against the ledger.
The reason field is where it surfaces
When determination goes wrong, the field that reports it is rarely the field that caused it. The rate is a number and numbers are accepted. What fails is the exemption reason attached to a nil rate, because that is the one place where a business decision, a code list and a national profile rule all have to agree at once, and it is the field most often populated by a default that predates the mandate.
Doing the work in the right place
There is a strong temptation to push determination outward — to let a service provider decide the treatment because their platform advertises country coverage. Resist it on evidentiary grounds rather than commercial ones. Determination depends on facts about the customer, the goods and the delivery that live in your source systems. A platform sees the document you gave it. It can check the document for consistency, and it can apply country rules to what it has been told, but it cannot know that the delivery address on this order is a temporary site rather than an establishment.
The general architecture question — what belongs in the source system and what belongs at a provider — is worked through separately. For determination specifically the answer is not balanced: the decision belongs where the facts are, and the facts are upstream. The European semantic model then carries the result outward in a form a stranger can check.
What this actually asks of a finance function
Not new expertise. The rules are the ones the team already applies. What it asks is that the application be moved earlier, be made explicit, and be made repeatable — which is to say, that decisions currently held in the heads of two people become configuration that can be tested. That is a documentation exercise and a data exercise, and it is almost always underestimated because it does not look like either compliance or IT.
The organisations that find the transition easy are not the ones with the best software. They are the ones that could already say, before the project started, which rule produced the tax on any given line.
