How to Check Your Omani Business Is Really Registered on Oman's SMP
Your provider accepting on Fawtara is not the same as being reachable. What Oman SMP registration creates, its three-working-day clock, and how to check it.
Your provider accepting your connection request on Fawtara does not make your business reachable. Registration on Oman's central SMP is a separate step that your provider performs afterwards, and the Tax Authority's own solution architecture gives them three working days to do it. Until it is finished, three things do not exist: your participant identifier on the SMP, a service group listing the document types you accept, and a lookup record at the Peppol service metadata locator that points senders to Oman's SMP. Nothing in the portal tells you when that happens.
You can check it yourself in under a minute, and you should — because the check is exactly the one a supplier's access point runs before sending you anything.
This page is for a finance or tax manager whose provider has already accepted. If you have not reached that point, the portal sequence is on how to connect your Omani business to an accredited service provider, and what to settle before you press Connect is on what to settle with an Oman service provider before you connect.
What does "reachable" actually mean in Oman?
It means three records exist, created in that order by your provider.
The architecture sets out step 3 of taxpayer setup as three actions. Your provider registers your participant identifier and service group on the SMP, and the portal validates that step. Your provider then updates the service group with your receiving capabilities, and the portal validates that step too. The SMP then tells the SML to create the participant lookup record, and the SML checks the identifier is unique before creating it.
That last record is a DNS entry. The architecture describes it plainly: after your metadata is updated in Oman's SMP, the SMP sends a request to the SML's management interface carrying only your participant identifier and the Oman SMP's domain name, authenticated with the SMP's authorisation certificate, and the SML creates or updates a CNAME record pointing your participant identifier at the SMP's hostname.
The practical consequence is worth stating once: a sender never asks Oman's portal anything. A sending access point resolves your identifier through the SML, fetches your service group from whichever SMP the SML names, and reads what you accept. If those records are absent, an invoice addressed to you cannot be delivered, and no amount of portal status changes that.
What is your Oman participant identifier?
It is your VAT identification number with a scheme code in front of it.
The architecture states that Oman issues a twelve-digit VAT identification number to
organisations that are Oman VAT registrants, that these act as sender (C1) or receiver (C4),
and that the participant identifier scheme is 0248 in the Peppol participant identifier
scheme code list. Its own worked example is 0248:OM1100003554.
You do not create this and you cannot choose it. It appears in three places: inside the business documents, in the transmission envelope, and in the SMP. That last one is the registration this page is about.
Five identifiers in that scheme are not registrations. Where a buyer is not on the network, the architecture assigns a fixed substitute identifier chosen by the invoice's transaction type:
| Situation | Substitute participant identifier |
|---|---|
| Deemed supply, business-to-business only, where the invoice must not be shared with the buyer | 0248 997770000096 |
| Exports, where the receiver is not registered in Peppol | 0248 997770000097 |
| A self-billed import invoice not subject to Oman's e-invoicing regulations | 0248 997770000098 |
| Domestic business-to-consumer, and profit-margin scheme invoices | 0248 997770000099 |
| A domestic buyer outside the Peppol network during the partial rollout, excluding B2C | 0248 997770000095 |
These identify a receiver inside a document. Nothing resolves to them and nobody is registered against them, so seeing one in your own system is not evidence about your own registration.
What has to be in your service group?
Two document types always, and two more only if you agreed them.
The service group is the list of what you can receive, and it is what the rest of the network reads before addressing anything to you. The architecture divides it:
| Document type | Status for a domestic Omani invoicing organisation |
|---|---|
| Oman PINT Invoice | Mandatory receiving capability |
| Oman PINT Credit Note | Mandatory receiving capability |
| Oman PINT Self-billed Invoice | Optional — only for participating organisations |
| Oman PINT Self-billed Credit Note | Optional — only for participating organisations |
Each entry appears as a document type identifier. The Oman PINT invoice is written
urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@om-1::2.1,
and the credit note is the same string with CreditNote in place of Invoice. The self-billed
pair substitutes selfbilling-1@om-1 for billing-1@om-1. You do not need to be able to write
these; you need to be able to recognise whether four came back or two.
Two entries is a complete registration for most businesses and an incomplete one for some. If a large customer raises invoices on your behalf, self-billed documents will be addressed to your identifier, and they will only arrive if your provider registered that capability. Why those documents behave differently is on correcting a self-billed invoice in Oman.
One entry you should not expect to find against your own identifier is the Message Level Status, the technical receipt reporting whether a document validated. The architecture requires your provider to register that against its own service-provider identifier, not yours.
How long does your provider have?
Three working days to put you on, one working day to take you off.
The architecture states both as obligations on the accredited service provider. They must add you to the central SMP within three working days of the relationship being established on the Fawtara portal. When a portal relationship ceases to exist or is terminated, they have one working day to deregister you.
Those two numbers do not overlap in your favour when you change provider: the outgoing provider must remove you within one working day while the incoming provider has three working days to add you. The gap that creates, and the effective date that controls it, are covered in the page on what to settle with a provider before you connect.
Three working days is a deadline, not an estimate. It is in the Tax Authority's own architecture rather than in your contract, which makes it a straightforward thing to hold a provider to on day four.
How do you check it yourself?
Query the network the way a sender does, and read what comes back.
The lookup has two legs. The first resolves your participant identifier through the SML to the SMP holding your record — in Oman, the Tax Authority's central SMP. The second asks that SMP for your service group, which returns one reference per document type you can receive. A registered participant returns that list. An identifier with no record returns nothing, and that is a valid answer rather than an error.
You do not need any tooling to do it. Our
free Peppol lookup runs both legs and shows the result: choose scheme
0248 — Oman Value Added Tax Identification Number, enter your twelve-digit VAT
identification number, and read the document types it returns. It searches every SMP on the
network rather than only the one GoRoute operates, so it answers the same question a supplier's
access point would ask. If you would rather query the SMP directly, the request format and the
identifier syntax are in the developer documentation.
Run it on a supplier or customer as well. The same lookup answers "can I send them an e-invoice yet", which is the other half of the question and the one that usually arrives first.
What does each answer mean?
| What the lookup returns | What it means | What to do |
|---|---|---|
| Four document types, invoice, credit note and both self-billed | Fully registered, self-billing included | Nothing. Record the date |
| Two document types, invoice and credit note | Registered, and correct unless you expect self-billed documents | Confirm with your provider whether the self-billed pair was meant to be there |
| Nothing found, inside three working days of acceptance | Normal. The registration clock is still running | Wait, then re-check |
| Nothing found, past three working days | A missed obligation | Ask your provider for the identifier they registered, then re-check yourself |
| A record against an identifier that is not your VAT identification number | The wrong participant was registered | Raise it immediately — documents addressed to you will not arrive |
Why can a registration be refused even when your provider tried?
Because the SMP asks the portal first, and takes no for an answer.
This is the part that explains most silent failures, and it is in the Tax Authority's own manual. A service provider manages participants through API calls to Oman's SMP. When one arrives — to add, amend or remove a taxpayer — the SMP queries the Fawtara portal to verify that a valid connection between that provider and that taxpayer has been established. If it has, the action status returned is Approve and the participant is added, amended or removed. If it has not, the status is Reject, no change is made to the participant record, and the process ends without any update.
So the portal connection is not paperwork that precedes the technical work. It is the authorisation the technical work is checked against, every time. The architecture reinforces the separation from the other side: the portal should not update the SMP directly, but manage the process of update requests and approval.
Two things follow for you. A provider who says they have registered you but whose portal connection lapsed has not registered you, and the SMP will have told them so. And a registration cannot be done "in advance" of the portal step by a friendly provider — there is nothing for the SMP to verify against.
What if you are still not there after three working days?
Ask for the two specifics, then check them yourself rather than accepting a confirmation.
Ask your provider for the participant identifier they registered and the document types they attached to it. Both are facts they can read off their own SMP management screen; the manual describes that screen as a list of participants connected to the service provider, with a detail view per participant, reached by logging in as a service provider and opening SMP management from the E-Services menu. Then repeat the lookup yourself and compare.
That comparison catches the two failures worth catching. A wrong identifier — a transposed digit in a twelve-digit number — produces a record that exists and never receives anything, because senders address the number on the invoice and not the one on the SMP. A short capability list produces a business that receives invoices normally and silently never receives the self-billed documents a major customer is sending.
If the connection itself is the problem rather than the registration, the statuses and what each one means are on how to connect your Omani business to an accredited service provider, and if you are reconsidering the provider entirely, the six questions are on how to choose an e-invoicing service provider in Oman.
What this page does not cover
Penalties. Neither the architecture nor the manual states a penalty for a missing or late SMP registration, so no figure appears here. Ask the Tax Authority or your tax adviser.
Becoming an accredited provider. Registering participants is a provider's job and it needs accreditation, its own certificate and its own SMP interface. That is a different reader, and the Authority publishes a separate manual for it.
VAT-return treatment. Nothing in either source describes how a registration gap interacts with a VAT return. We are not going to infer it.
Related Oman guides
- How to connect your Omani business to an accredited service provider — the portal sequence that has to finish before any of this starts.
- What to settle with an Oman service provider before you connect — where the receiving capabilities above are actually decided.
- How to choose an e-invoicing service provider in Oman — the decision before both of them.
- Correcting a self-billed invoice in Oman — why the optional capability is a real decision rather than a default.
- Peppol in Oman: Fawtara readiness — the programme and the network your identifier is registered on.
What to do next
Look yourself up on day three, not on the day an invoice fails. The check takes a minute,
it needs nothing but your VAT identification number, and it is the only evidence that the
registration your provider owes you actually happened. Use the
free Peppol lookup with scheme 0248.
Count the document types, not just the presence of a record. Two is right for most businesses and wrong for anyone receiving self-billed invoices.
The commercial ground for Oman, including where GoRoute sits on the accredited list, is on our Oman Fawtara e-invoicing page. Connector walkthroughs for the systems that feed your provider are on tutorials, and the participant, service-group and document-type detail behind this page is in the developer documentation. To have your own registration and receiving capabilities checked against these rules with our team, book a session.
Sources: the Oman – Solution Reference Architecture v1.0.3 of 27 July 2026 (Final; OpenPeppol
AISBL with the Oman Tax Authority), section 3.2 step 3 and Figure 9 for the participant
identifier and service-group registration, the receiving-capability update and the SML lookup
record, section 3.4 for the three-working-day registration and one-working-day deregistration
obligations, section 6.1.1 for the mandatory and optional receiving capabilities and for MLS
being registered against the provider's own identifier, section 10.2.1 for the Oman PINT document
type identifiers, section 10.3.1 for the 0248 participant identifier scheme and the five
substitute identifiers, and section 12.3 for the separation between the portal and the SMP; and
the Oman Tax Authority's Service Provider and Taxpayer Association Management User Manual v1.0,
section 10 for the service provider's participant list and detail screens and section 11 for the
SMP's Approve and Reject responses to a provider's add, amend or remove request. The Oman PINT
specification is published at docs.peppol.eu, and
Oman's e-invoicing material by the
Tax Authority.
Frequently asked questions
- How do I know my business is registered on the Oman SMP?
- Look it up, rather than asking. Registration creates a public record: your participant identifier resolves through the Peppol service metadata locator to Oman's central SMP, and the SMP returns a service group listing one entry per document type you can receive. Any sender performs that same lookup before sending you anything, so the answer it gives is the answer that matters. An identifier with no record returns nothing — which is a valid answer, not a fault.
- What is my Oman Peppol participant identifier?
- It is Oman's VAT identification number, prefixed with the Peppol scheme code 0248. The solution architecture states that Oman issues a twelve-digit VAT identification number to VAT registrants, that these act as sender or receiver on the network, and that the scheme code 0248 is registered in the Peppol participant identifier scheme code list. Its own worked example is 0248:OM1100003554. You do not create it and you cannot choose it.
- How long does my provider have to register me on the Oman SMP?
- Three working days from the relationship being established on the Fawtara portal. The architecture states it as an obligation on the accredited service provider, not as a target. The reverse clock is shorter: when a portal relationship ends, the provider has one working day to deregister you from the central SMP.
- Which document types should appear against my identifier?
- The Oman PINT invoice and the Oman PINT credit note, always. The architecture makes both a mandatory receiving capability for domestic Omani invoicing organisations. The Oman PINT self-billed invoice and self-billed credit note are optional and appear only if you agreed them with your provider. If you expect self-billed documents and only two entries come back, the registration is incomplete for your business even though it is technically valid.
- Why might my SMP registration be refused even though my provider tried?
- Because the SMP checks the portal before it acts. The Tax Authority's manual states that when a service provider calls the SMP to add, amend or remove a participant, the SMP queries the Fawtara portal to verify that a valid connection between that provider and that taxpayer exists. If it does, the action status is Approve and the change is made. If it does not, the status is Reject, no change is made to the participant record, and the process ends without any update.
- What should I do if I am still not reachable after three working days?
- Treat it as a provider obligation that has not been met, and say so in those words. The three-working-day registration deadline is in the Tax Authority's own solution architecture, so it is not a service-level term you negotiated. Ask your provider for the participant identifier they registered and the document types they attached to it, then repeat the lookup yourself rather than accepting a confirmation.
- Does the Fawtara portal show me my SMP record?
- Not to you. The manual's SMP management screens — the list of participants and the selected participant's details — are described under actions taken by service providers, reached by logging in as a service provider and opening SMP management from the E-Services menu. Your own view is the Manage Service Provider page, which shows who you are connected to and since when, not what exists on the SMP.
- What identifier is used when my buyer is not on Peppol?
- One of five fixed substitute identifiers, chosen by the invoice's transaction type. The architecture assigns 0248 997770000096 to a deemed supply that must not be shared with the buyer, 997770000097 to exports where the receiver is not registered in Peppol, 997770000098 to a self-billed import invoice outside Oman's e-invoicing regulations, 997770000099 to domestic business-to-consumer and profit-margin invoices, and 997770000095 to a domestic buyer outside the network during the partial rollout. They identify the receiver in the document; they are not registrations and nothing resolves to them.
About Dr. Syed Raza
Dr. Syed Raza is an IT Enterprise Architect at ClayDesk LLC and leads the GoRoute platform. He works across Peppol Access Point and SMP infrastructure, PINT jurisdictions (Oman, AU/NZ, EU, JP, MY, SG), and national CTC regimes, translating regulatory detail into production-grade e-invoicing systems.
Building on Peppol?
GoRoute is a certified Peppol Access Point & SMP. Book a demo or read the docs to get started.