Oman E-Invoicing from SAP S/4HANA: What You Configure

The short answer

Sending Oman e-invoices from SAP S/4HANA is a configuration job, not a development one. You activate the standard communication scenario SAP_COM_0120 (Billing Integration), create a communication user for your service provider to authenticate as, and put Oman's party identifiers into master data. There is no ABAP to write and no transport to move. The real work is not in SAP at all: it is making sure your billing documents carry the data Oman's rule set requires, and finding that out by validating real documents early rather than at go-live.

The parts that are the same in every country — how the billing document leaves S/4HANA over the standard OData service, how it is mapped to UBL 2.1, and how it is transmitted over AS4 — are set out on the SAP Peppol integration page. This page is the Oman layer on top of that: what PINT OM and Fawtara add.

What has to change inside SAP?

Two things, and both are configuration.

Activate the communication scenario. SAP_COM_0120 — Billing Integration — is the standard scenario for sending billing documents to an external system. It is delivered with the system. Activating it is a configuration step in the communication management apps, not a change to your code base.

Create a communication user. That user is the identity your service provider authenticates as when it collects or receives billing documents. It is scoped to the scenario, which means it can do that job and nothing else.

That is the whole SAP-side change for the sending path. No ABAP, no transport. This matters more than it sounds: it moves the work out of a release window. A change that needs a transport inherits your release calendar, your regression testing and your change-advisory queue. A configuration change and a user do not.

What it does not remove is the analysis. Somebody still has to confirm which billing document types are in scope, which company codes, and what happens to the documents your business issues outside S/4HANA — the separate billing system, the point-of-sale estate, the spreadsheet somebody maintains. That list is usually longer than the first meeting assumes.

Which SAP scope item does this align to, and what does that mean?

GoRoute's SAP integration aligns to SAP Best Practices scope item External Billing (1Z6) for S/4HANA Cloud Public Edition, and Oman is listed among the regions that scope item supports.

Read that sentence precisely, because it is easy to inflate:

• "Aligns to" is the claim. We follow the integration pattern SAP documents. SAP does not endorse GoRoute, and no provider should tell you otherwise.
• 1Z6 is a billing-integration scope item, not a compliance one. It describes how a billing document gets from S/4HANA to an external system. It says nothing about whether the resulting invoice satisfies Oman's rules. Those are two different problems and only one of them is solved by SAP.
• Oman being a supported region is about the scope item, not about your licence. Check your own contract and system version rather than inferring either from an article.

The practical value of following the documented pattern is boring and real: when SAP updates the system, an integration that uses the standard scenario keeps working, and one built around a modification is somebody's project again.

What does Oman need in your master data?

Oman uses Peppol scheme 0248, and the party identifier is the VAT identification number carried with an OM prefix. It is required for the seller and for the buyer.

This is where SAP projects actually stall, and the reason is organisational rather than technical. The identifier lives in customer master data, which is owned by whoever owns customer master data — usually not the team doing the integration. Getting it populated across an existing customer base is a data exercise with a queue in front of it, and it is worth starting on the day the project starts rather than the week the testing does.

Two habits save weeks here:

• Fix the seller side first. Your own company codes are a handful of records and they are entirely in your control. Getting them right removes half the noise from early test results.
• Sample the buyer side before you extract it. Run a count of how many active customers are missing a usable VAT identifier. That number is the size of the data workstream, and it is better known in week one than in week nine.

How do you know an invoice will be accepted?

By validating a real one, early. GoRoute validates a document against the full PINT OM 1.0.1 rule set, including its Schematron rules, and returns a compliance score with human-readable errors — not a bare pass or fail. An error that names the field and the rule is a ticket somebody can action; a rejection code is a conversation.

Two things make this cheap enough to do properly:

• Validation-only calls carry no per-call charge, along with status lookups and webhooks. Billing is per document exchanged. So validating the same document forty times during a build costs nothing, which is exactly the behaviour you want from a team getting a mapping right.
• You can validate before you can send. The rule set does not wait for anything, so a project can be working through real errors on real data while the commercial and onboarding steps run in parallel.

The failure mode this avoids is the standard one: a project that tests with three hand-made invoices, passes, and discovers at volume that half of the real customer base carries something the rule set rejects.

How do you move a month of invoices rather than one?

Batch submission takes between 1 and 1,000 invoices in a single request, with separate validate and process stages so you can check a batch before committing it.

This is a design decision worth making early, because it is expensive to retrofit. Integrations built as one call per document usually work fine in testing and then meet month-end, when the volume arrives in an hour rather than spread across a day. If your S/4HANA billing runs are periodic — and most are — the batch shape matches the way your business already issues invoices.

Does the QR code apply to our B2B invoices?

No. The Fawtara QR code is a business-to-consumer feature. It appears on the human-readable invoice a consumer receives, which is delivered outside the Peppol network, alongside a tax data document that carries an embedded simplified invoice.

It is worth being explicit about, because the QR code is the most visible part of Oman's programme and it gets described as though every invoice must carry one. If your S/4HANA billing is business-to-business, the QR code is not the feature you are integrating for. If you also run retail or point-of-sale, that is a separate path with its own requirements, and it should be scoped separately rather than folded into the ERP workstream.

What happens to documents before the Authority's production environment opens?

They are preserved with their original issue time and released when the Authority's production environment opens. The issue time on the document remains the issue time.

We do not publish a date for that opening, because no firm date has been announced. Anyone quoting you one should be asked for the source. What you can plan around is the arrangement itself: work done now is not work sitting idle, and documents produced now are not re-dated later to make a system look tidy.

Where do the invoices live?

For Oman, in Oman: GoRoute operates in-country data residency on Otech's Tier III Oracle Cloud Infrastructure region, covering invoices, keys, tax data documents and audit logs. GoRoute operates ISO 27001-aligned practices on certified cloud infrastructure.

Data residency is usually raised late in an SAP project, by the security review, at the point where changing the answer is expensive. It is a cheaper question in week one.

What this page deliberately does not tell you

The mandate dates and the revenue threshold. They are not omitted because they are unclear — they are set out in full on the page that covers Oman's e-invoicing dates, with the decision that fixed them. One page should own that question, and it is not this one.

Whether your particular entities are in scope. That depends on your group structure and your registrations, and it is a question for whoever advises you on tax rather than for an article.

How long your project will take. Anyone quoting a duration without seeing your billing document types, your company codes and the state of your customer master data is quoting a number, not an estimate.

Running a different system?

The same question, answered for the systems next to SAP in most Omani finance functions: Odoo e-invoicing in Oman, TallyPrime and Oman's e-invoicing programme, connecting TallyPrime to the Peppol network, and, where there is no integration at all yet, sending Oman e-invoices from a spreadsheet.

If the people you are scoping this with would rather watch than read, the Odoo page is the one to send them: it describes two recorded demonstrations of an invoice leaving an ERP, clearing PINT OM validation and coming back with a status. The mechanics on screen are the same ones this page asks you to configure in SAP.

For the product view of the SAP connection rather than the regulatory one, see the SAP integration page; for the market as a whole, the Oman page. If it is easier to talk it through against your own system, book a working session.

Where GoRoute stands

GoRoute is an e-invoicing service provider accredited in Oman by the Oman Tax Authority, on 29 July 2026, through Union Digital Technologies SPC. It operates a Peppol-certified Access Point (Service Provider ID POP000991, ClayDesk LLC), and re-certified PINT OM v1.0.1 conformance in July 2026 with all test suites passed — Billing and tax data document 7/7, self-billing 7/7, reporting 2/2, eDelivery 7/7, and BIS Billing 5/5.

Those are checkable facts rather than adjectives, which is the point: ask any provider for the equivalent.

Sources

• PINT OM Billing Process v1.0.1 — the Oman specification the validation rules come from
• Oman Tax Authority tax portal
• OpenPeppol — the network the exchange runs on
• SAP Signavio Process Navigator, scope item External Billing (1Z6)
• SAP Business Accelerator Hub, Billing Document API — the communication scenario and communication user

Every source above was requested on the day this page was prepared and answered normally. The two SAP pages draw their content with JavaScript, so they need a browser rather than a plain fetch; the scope item and communication-scenario details behind them were verified by a person in August 2026.