Localisation and e-invoicing in SAP S/4HANA

After station seven your books are correct. This station asks something else: are they acceptable to the tax authority in your country?

The question is not academic. A company that cannot issue an acceptable invoice cannot sell — however disciplined its system is on the inside.

Three layers everybody conflates

More than half the argument about “does the system support my country?” comes from folding three separate things into one question:

Layer	What it means	Its status in this product
Language	Interface and report translation	Native, with Arabic supported in the product itself
Accounting localisation	A local chart of accounts, taxes and report formats	Inside the country localisation packages
Technical tax compliance	Signing the invoice and transmitting it to the authority’s platform	A separate product from the same vendor

The first two layers are a matter of configuration. The third is a matter of law, and it alone carries rejections, deadlines and fines. So when you assess any system, ask about the third by the explicit name of the government platform in your country — not about “Arabic support”.

The plain answer, and it differs from what you expect

Here is the substantive difference between this product and the systems that refer you to a third party:

The vendor ships a compliance product under its own name — a product built for document compliance and regulatory reporting, covering both phases of e-invoicing in Saudi Arabia and the UAE requirement.

But it is licensed separately, and it needs its own implementation.

Read both sentences together, because plenty of people read the first and stop. This is a third position between “included” and “third party”, and it carries properties of each:

Question	Included in the product	A separate product from the vendor	Third party
Who updates when the specification changes?	The vendor, inside the release	The vendor, on the add-on product’s own schedule	The third party, on theirs
Does it carry its own price line?	No	Yes	Yes
Does it need an implementation project?	No	Yes	Yes
Who do you turn to when an invoice is rejected?	One party	One party	Two, and they may refer you to each other

The last row is what you are actually buying with that extra line on the invoice: one party to ask. That is not a small advantage on the day an invoice is rejected during a month-end close.

The second row is where buyers get caught, because the vendor’s name is on the product and it reads as already paid for. It is not.

So the rule you leave with: do not ask “does the system support e-invoicing?” — ask “is it included in my quotation, on which price line, and how many implementation days?” Anyone who asks it in that form in a system-selection meeting saves their company a year of surprises. The full invoice structure, with the lines usually left out of it, is in the SAP S/4HANA guide.

Why the correction rule turned out to be a feature

At station five, refusing to edit an issued invoice looked like conservative accounting practice, with the correction as a separate linked document.

Now the reason appears. Every e-invoicing regime in the world imposes the same rule: an invoice that has been signed and transmitted to the tax authority is neither edited nor deleted, and the correction is a separate document linked to it.

So a product that allows an issued invoice to be edited is a product that will have to be constrained later to work with any tax specification at all. The discipline that felt like a restriction in week one is the requirement you receive already met in month six.

The seven questions before any promise

This list holds for any system and any country, and it is the most useful thing you take from this station:

1. What exactly is the government platform called, and which phase is it in now?
2. Is the compliance product inside the quotation, or a separate line?
3. How many implementation days does it consume, and who implements it?
4. Does it work with the deployment shape you will run? Public cloud and on premise are not the same thing.
5. What is the response time when the government specification changes?
6. Who signs the digital certificate, and who holds its key?
7. What is the emergency procedure when an invoice is rejected on a working day?

Questions six and seven are the two nobody asks and everybody pays for. Anyone who can copy your signing key can issue invoices in your name — which on its own ends the evaluation of any provider offering to keep your key somewhere it can be copied from.

If you want the requirements themselves independently of any system, they are set out in ZATCA phase two and e-invoicing in the UAE.

What you actually do at this station

You will not build a real integration in a training environment, and nobody expects you to. What is expected is that you build the structure any integration consumes, which is nearly identical across every specification:

• The entity’s tax registration number and its full address in separate components, not as one block of text.
• The counterparty’s tax number on the business partner record — and here the unified partner from station three pays off: one identity, not two.
• A separation between the business invoice and the individual invoice, because the specifications differ on what each must contain.
• An explicit tax structure at line level, because every specification wants tax itemised rather than aggregated.
• An unbroken numbering sequence, because a gap in invoice numbering is an inspection question before it is a system matter.

Then issue a complete invoice and read it with an inspector’s eye: does it carry every mandatory element, or does it carry a field you assume somebody will fill in later?

The commonest localisation error

Setting tax at item level instead of through tax conditions. It works in the demonstration, then collapses the first time the same item is sold to an exempt customer and a taxable one, or the first time a rate changes by decree.

And the rule — the same rule that governed pricing at station five: tax is a property of a relationship between two parties on a date, not a property of a thing.

The acceptance test for this station

1. Write one page answering the seven questions for your own country. That page is a portfolio piece, and the closest thing you will write to real consulting work.
2. Populate the tax data for one entity and two partners: a company with a tax number and an individual without one.
3. Issue two invoices — one of each kind — and compare what appears on them.
4. Write the difference in three lines between “included”, “a separate product from the vendor” and “third party”, with each one’s effect on the invoice and on responsibility.
5. Issue a credit note and explain in one sentence why every e-invoicing regime imposes that sequence.

What comes next

You know the boundary between what the product ships and what is bought beside it. The next station asks: what do you do when what you bought is not enough? — with a four-rung ladder, a different ceiling for each deployment shape, and why a mandatory twice-yearly upgrade is the thing that decides what you may promise.