Localisation and e-invoicing in SAP Business One

At station seven your numbers became correct. Correct is not enough.

A correct number rejected by the tax authority is worth nothing, and an invoice that is accounting-sound but not accepted electronically is not collected.

This station is the one most attached to the contract rather than to the screen. Anybody who masters it sits in the meeting before signature, not in the implementation meeting.

The distinction that settles everything

Localisation and compliance are not one thing, and they do not come from the same party.

	Localisation	Electronic compliance
What it is	A tax model, accounts and country reports	Sending the invoice to the authority’s platform in its format
Who ships it	The developing company, with the product	The partner or an external provider, as an add-on
When it changes	Rarely	With every amendment to the regulation
Who bears a delay in it	Nobody, in practice	Whoever the contract names — or the client

The last row is the whole station.

What comes with the product

The product ships with dozens of country localisations and an interface that supports Arabic, and its official list includes several Arab countries — among them Saudi Arabia, the UAE, Egypt, Qatar and Oman.

“Localisation” here has a defined meaning: the tax model, the chart of accounts template, the report formats required locally, and handling of the country’s accounting particularities.

That localisation was chosen once when the company was created and is not switched afterwards by a setting — it is the first of the four decisions at station three, and now you know why it was first.

What does not come with it — and this matters more

Connecting the electronic invoice to the authority’s platform is not standard functionality in the product.

The second-phase requirements in Saudi Arabia — integration with the authority’s platform, the signature, the QR code and the approved format — are delivered through an add-on from the partner or a specialist provider. The same holds in the UAE with the e-invoicing direction there.

The conclusion has to be stated plainly: your legal conformity is written in a third company’s code.

That is not a complaint; it is a description. And the description is useful because it leads to three questions asked before signature rather than after:

1. Who ships the update when the regulation changes? The partner? Or the add-on provider? The party is named in the contract.

2. In how many days? “We will update it” is not a duration. The duration is written in days.

3. Who bears the penalty if the update is late? That is the question that actually changes a contract, and it goes unasked on ninety per cent of projects.

The contractual clause is the remedy, not a technical setting. No configuration in the system compensates for its absence.

Why this matters to a learner rather than a buyer

Because it separates you from everybody who explains screens.

Somebody who knows that compliance arrives as an add-on, that its source is asked for by name, and that the update window is written in days — says things in a first meeting that a year of screens does not teach.

The consultant’s working rule: never promise compliance whose supplier you have not read. Promising a country’s tax treatment without having read that country’s regulation is the fastest way to lose a client after signature rather than before.

Language and direction — a detail tested with the eye

An Arabic interface means, literally, an Arabic interface in its printed output too.

The only acceptable test is to print a document — an invoice with its figures, its tax and its address — and look at it. Direction problems in printed documents are not exposed by an on-screen test, and most of them appear in numbers and dates sitting inside Arabic text.

Do not rely on a statement of support; rely on a printed document in your hand.

What you actually do at this station

• Read your country’s regulation yourself from the authority’s site, and record the date you read it — regulations change and articles are not updated.
• Examine the tax configuration in your environment: where rates are defined, how they attach to the partner and to the item, and which one wins when they disagree.
• Post three invoices with different tax treatments — standard-rated, exempt and zero-rated — and read the entry for each.
• Produce the tax report and reconcile it by adding the three invoices up by hand.
• Print a complete invoice with the data your country requires, and look at it.
• Write the three questions above on a sheet and keep it. That sheet is used in a meeting; it is not a training exercise.

The three commonest errors

One: assuming compliance is part of the licence. It is assumed without asking, and discovered weeks after signature when the add-on’s name and price are requested.

Two: setting tax at item level from the start. It works, then one rate changes and the amendment becomes a project — the same logic that governed account determination at station three, and the rule is identical: configure at the highest level that suffices.

Three: deferring partners’ tax numbers. Warned about at station three, and paid for here: an invoice rejected because the customer’s number is missing, on the day the first tax file is filed.

The detail of who ships compliance and what it does to the contract and the price is in the SAP Business One guide.

The acceptance test for this station

1. Explain the difference between localisation and compliance, and who ships each.
2. Write the three questions asked before signature, in their contractual form.
3. Post three invoices with different tax treatments and read their entries.
4. Produce the tax report and reconcile it by hand against the invoices.
5. Print an invoice and judge a printed document rather than a screen.

What comes next

Compliance is understood. The next station draws the line that decides your project’s lifespan: customisation and extension — where configuration ends and code begins, and what survives an upgrade against what is tested at every one.