Buyers outside Oman who accept only BIS 3.0

Some buyers outside Oman are on Peppol but accept only Peppol BIS Billing 3.0, not PINT OM. When you send an invoice or credit note as invoice data (POST /api/v1/invoices, drafts, CSV import or an ERP connector) to a buyer outside Oman whose Peppol registration lists BIS Billing 3.0 and not PINT OM:

The buyer receives a BIS Billing 3.0 copy of the invoice over Peppol. It has the same number, issue date, parties, lines and amounts, and carries the PINT OM invoice's UUID in an AdditionalDocumentReference.
The PINT OM invoice remains the invoice of record and is reported to the Oman Tax Authority once the copy has been delivered. The PINT OM send itself is refused first, because the buyer does not accept PINT OM. GoRoute does not report that refusal to you as a failure. Once the copy has been delivered and the report filed, your transaction shows as delivered and the tdd.reported_via_bis_copy event links it to the copy.
If the copy could not state exactly what the PINT OM invoice states, it is not sent. In that case, or if the copy cannot be delivered, the invoice is reported the same way as an invoice to a buyer who is not on Peppol. See BIS 3.0 buyer copy for when this happens.
You are not billed for the copy as a second document.

A buyer registered for PINT OM (including through the PINT billing wildcard) receives the PINT OM invoice as usual. UBL you submit yourself to POST /api/v1/documents is transmitted as submitted and gets no copy.

BIS 3.0 buyer copy

When a copy is made

GoRoute makes a BIS 3.0 copy only when all of these are true:

You sent the invoice or credit note as invoice data, so GoRoute rendered the PINT OM document itself. The copy is rendered from the same invoice data.
The seller is in Oman and the buyer is outside Oman.
The buyer's Peppol identifier is not an Omani (0248) or tax-authority (0242) one.
The PINT OM send was refused because the buyer does not accept PINT OM, and the buyer's Peppol registration lists the BIS Billing 3.0 document of the same kind (invoice or credit note).
Nothing has been reported for the invoice yet.

Before sending, GoRoute compares the copy with the PINT OM invoice field by field: number, issue date, type code, currencies, the preceding invoice of a credit note, both parties (electronic address, legal name, VAT number, country), every line (quantity and unit, net amount, item name, VAT category and rate, net unit price), the VAT breakdown and every total. If any of them would differ, no copy is sent.

When the stand-in is used instead

The invoice is reported under the §10.3.1 stand-in participant 0248:997770000097 with scope INP, exactly as for a buyer who is not on Peppol, when:

An amount has a non-zero third decimal. BIS 3.0 states prices and amounts to two decimals, so, for example, a unit price of OMR 0.229 cannot be copied. OMR amounts whose third decimal is 0, such as OMR 25.500, are copied.
A unit, VAT category or other compared field would differ between the copy and the PINT OM invoice.
The copy fails BIS 3.0 validation, or cannot be queued.
The buyer's Access Point refuses the copy at the Peppol transport, or the copy's send otherwise fails for good.
GoRoute gives up on the copy: the job that makes it fails on every attempt, or the copy's send is abandoned before it was handed to the Peppol transport. The copy then shows as failed with error_code SEND_DEAD_LETTERED. The invoice is never left unreported. (A copy whose send is abandoned after it was handed to the transport may have reached the buyer. No report is filed automatically for it: GoRoute's operators check the Peppol receipt and file the report that matches, through the copy if it was delivered, the stand-in if it was not.)
The copy is switched off for your environment.

In every one of these cases the reason is recorded on the transaction: metadata.oman_reporting.bis_copy_status is skipped (no copy was sent; bis_copy_skipped_reason says why) or failed (the copy was sent and failed; bis_copy_error says why).

Buyers whose Access Point still runs BIS 3.0.20

Oman's 0248 identifier scheme first appears in the Peppol list of electronic address schemes in BIS Billing 3.0.21 (May 2026). An Access Point that still validates with 3.0.20 rejects the copy, because the seller's electronic address carries schemeID="0248" (PEPPOL-EN16931-CL008, BR-CL-25). The same is true of any BIS 3.0 document from an Omani sender. Two things can happen:

The Access Point refuses the copy at the Peppol transport. The copy has failed, so the invoice is reported under the stand-in with scope INP.
The Access Point accepts the copy and then rejects it with a negative Message Level Status (RE). The invoice has already been reported with scope IP. The rejection is recorded on your invoice and sent to you as mls.received and response.rejected, naming your invoice. It is the buyer's answer, not the Tax Authority's, so no tdd.rejected is sent for it. As for any invoice whose buyer rejects it, GoRoute then files a Disregard of the invoice's report. Send the buyer the invoice by another route and contact support if the report needs correcting.

What IP and INP mean for you

Scope	When	What it means for you
`IP`	The BIS 3.0 copy was delivered over Peppol.	The buyer has the invoice. The PINT OM invoice was reported as an international invoice exchanged over Peppol. Nothing more to do.
`INP`	No copy was made, or it could not be delivered.	The buyer does not have the invoice. It was reported as an international invoice not exchanged over Peppol, under the stand-in `0248:997770000097`. Send the invoice to the buyer yourself, for example as a PDF.

Events you receive

Neither case sends transaction.failed for the PINT OM send the buyer refused. The event that reports the outcome is sent instead:

Outcome	Events, in order
Copy delivered, reported `IP`	`transaction.delivered` for the copy's transaction, then `transaction.delivered` for your invoice (with `delivered_via: "bis_copy"`) and `tdd.reported_via_bis_copy` for your invoice.
Stand-in, reported `INP` (including a buyer not on Peppol at all)	`tdd.reported_via_substitute` for your invoice.
Copy delivered, but the report then failed	`transaction.delivered` for the copy's transaction, then `transaction.failed` for your invoice, with `fallback` set to `bis_copy`. The buyer has the invoice, but it was not reported. Contact support.
The stand-in report could not be filed either	`transaction.failed` for your invoice, with `fallback` and `fallback_error`. The invoice was not reported. Contact support.

See Omani invoices the buyer cannot take as PINT OM for the payloads. If your integration listens only for transaction.delivered and transaction.failed, add tdd.reported_via_substitute: an invoice reported under the stand-in sends neither.