B2B and B2C invoice flows under Fawtara

Fawtara readiness depends on the kind of invoices a business issues. A company that mostly invoices other VAT-registered businesses has a different workflow from a retailer issuing thousands of B2C receipts. Exports, imports, credit notes, debit notes, and self-billing add more variation.

The first step is not software selection. The first step is to classify invoice flows correctly.

Why invoice flow classification matters

Invoice flow controls implementation effort. A business should not describe itself as simply "VAT-registered" and stop there. It should know the mix of transaction types it issues every day.

Key questions:

• Do we invoice businesses, consumers, government entities, or all three?
• Which of our business customers are VAT-registered and connected to a service provider? That answer — not the customer's size or type — decides B2B or B2C for each invoice.
• Which invoices require real-time handling?
• Which invoices are B2C, where submission timing is not yet settled?
• Which documents are credit notes or debit notes?
• Do we issue export invoices?
• Do we have import or self-billing cases?
• Which systems create each type: ERP, POS, accounting software, Excel, or manual templates?
• Which teams correct errors when validation fails?

Without this map, a provider or software partner cannot size the implementation correctly.

"B2C" does not mean your customer is a consumer

This is the classification that catches businesses out, and it is worth getting right before you read the table below.

The dividing line is not whether your customer is a company or a shopper. It is whether your customer can be reached on the network. Asked what happens when the recipient is not VAT-registered and has no service provider, the OTA answers plainly: "This is a B2C scenario."

So if you invoice only businesses, you can still be on the B2C path. A client who is below the VAT registration threshold — a small consultancy, a sole trader, a new company — has no service provider to receive a structured invoice, so that invoice takes the B2C route no matter how commercial the relationship is.

What the OTA says happens in that case:

• you submit the invoice to your service provider as normal;
• your service provider submits the tax data only to the OTA;
• you give the customer the human-readable invoice yourself — physical, PDF, or otherwise — outside the Fawtara network, and it will require a QR code.

The practical test is therefore not "do I sell to consumers?" but "is this customer VAT-registered and connected to a service provider?" A business with a mixed client list is on both paths at once and needs both to work.

Main flow types

Use this working table when mapping your current process.

Flow	What it means	Readiness concern
B2B	Your customer is VAT-registered and reachable through their own service provider.	Real-time submission, buyer identifiers, validation, and correction handling.
B2C	Your customer cannot be reached on the network — a consumer, or a business that is not VAT-registered and has no service provider.	Submission-timing control (timing not yet settled), high volume, paper/readable output, and QR requirements on the human-readable invoice.
B2G	Business-to-government flows.	OTA has not yet finalized B2G-specific rollout details; plan against current source material.
Export	Oman seller invoices a buyer outside Oman.	OTA FAQ describes an export flow where buyer-side network participants are outside the exchange.
Import	Inbound supply handled through self-billing where applicable.	Process and source-document handling must be mapped carefully.
Credit note	Correction or cancellation of an earlier invoice.	Link to the original invoice and preserve the correction chain.
Debit note	Adjustment increasing a previous invoice amount.	Link to the original invoice and keep tax treatment consistent.
Self-billing	Buyer issues the invoice on behalf of the supplier.	Treat as a separate flow, not a normal supplier-issued invoice.

The PINT-OM data dictionary and business rules currently shared are a draft for consultation; OTA has said a final, official version will be released.

B2B: real-time operational pressure

B2B invoices need real-time handling. That makes error resolution important. If validation fails, the finance team needs to know what to fix, where the source data lives, and whether the invoice can be regenerated without breaking the invoice sequence or customer workflow.

For B2B readiness, check:

• customer VATIN and legal-name quality;
• electronic-address or routing identifiers where required by the final process;
• invoice approval steps before submission;
• how validation errors return to finance or operations;
• credit note and debit note handling;
• whether the provider path can handle normal business-hour peaks;
• archive links between source invoice, submitted document, validation status, and correction history.

Do not test only a clean sample invoice. Test a normal invoice, a credit note, a debit note, and an invoice with discounts or multiple tax rates.

B2C: volume and submission control

B2C invoices are different because volume can be high and customers may still need a readable paper or digital copy. The OTA Monthly FAQ (30 June 2026) confirms that only B2C invoices remain in paper alongside the electronic format after implementation. B2C submission timing, however, is not yet settled:

Sources disagree (checked 2026-07-14): OTA's Monthly FAQ (30 June 2026) gives B2C a 24-hour submission window; OTA's Service Provider FAQ says B2C timing is still under discussion, with no stipulated timeframe yet. Both are current official OTA sources. Plan for the stricter 24-hour case, but treat it as provisional and confirm with your provider before relying on it.

QR scope is also unsettled:

Sources disagree (checked 2026-07-14): OTA's Monthly FAQ (30 June 2026, §4.1.4) says a QR code is mandatory for all B2C invoices, full and simplified; OTA's Service Provider FAQ (Q15) says QR is expected to be mandatory only for simplified B2C invoices, and that the QR details are not yet finalized. Do not treat either scope as settled.

For B2C readiness, check:

• whether each transaction produces a separate e-invoice;
• whether POS or sales systems can export all transactions reliably;
• whether end-of-day batching would still meet a same-day submission window, if one is set;
• how failed submissions are retried and monitored;
• whether QR appears on the human-readable invoice where required;
• how refunds, returns, and credit notes are handled;
• whether branch-level systems use consistent item, tax, and customer data;
• how paper/readable copies relate to the structured e-invoice archive.

Do not rely on a daily PDF report as the compliance record. The business needs transaction-level structured data.

Exports, imports, and self-billing

The OTA FAQ confirms specific non-standard scenarios:

• export flow is described as C1 to C2 to C5, with buyer-side C4 and C3 outside the network;
• imports are handled via self-billing;
• adjustments use electronic credit or debit notes.

These cases should be separated in your data map. They often have different source documents, approvals, tax treatment, and correction paths.

Questions to ask:

• Which invoices are exports?
• Which import scenarios require self-billing?
• Who approves self-billed documents?
• How are original invoices linked to credit notes or debit notes?
• Can the accounting system export these cases separately from normal sales?
• Can your provider test these scenarios before go-live?

If a business has only a few of these cases per month, they can still cause disproportionate implementation risk because they are easy to forget during testing.

A practical flow-mapping exercise

Create a table of the last month of invoices and classify each transaction.

Column	Example values
Invoice number	Existing invoice or receipt number.
Issue date	Date issued.
Customer type	B2B, B2C, B2G, export.
Document type	Invoice, simplified invoice, credit note, debit note, self-billing.
Source system	POS, ERP, accounting software, Excel, paper.
Customer VATIN	Present, missing, not applicable, needs review.
Submission timing	Real-time (B2B), or to be confirmed (B2C).
Correction link	Original invoice reference if credit/debit note.
Archive location	Where source data and generated documents will be stored.
Owner	Team or person who fixes errors.

This exercise usually reveals more than a generic provider demo.

Common mistakes

• Treating B2B and B2C invoices as the same workflow.
• Assuming a B2C end-of-day report is the same as transaction-level e-invoices.
• Forgetting returns, refunds, credit notes, and debit notes.
• Not separating exports and self-billing cases.
• Waiting until integration testing to clean VATIN and customer data.
• Printing a readable invoice but not preserving the structured record.
• Testing only one invoice type before go-live.

What is not safe to claim yet

Do not publish or rely on the following without current primary evidence:

• exact QR/TLV tag rules or character limits;
• final PINT-OM field names for every B2B or B2C case;
• exact validation-rule counts;
• penalty amounts for late or failed submission;
• final B2G/government rollout details beyond the current source material;
• vendor claims that a POS or accounting connector handles every edge case.

The safe claim is narrower: B2B, B2C, export, import, credit/debit note, and self-billing flows should be mapped separately before choosing a provider or connector.

Next step

Take one month of invoices and classify every transaction by customer type, document type, source system, submission timing, and correction path. Then use that map in provider conversations and integration testing.

If you cannot classify the flows clearly, the business is not ready to choose a final technical path yet.