ZATCA-Compliant Invoicing for an Intermediary Services Platform¶

Six invoicing approaches and their implementation on Invora.

Audience: Platform engineering and integration teams.
Scope: How to invoice the customer-facing service supply and the platform's inter-party charge, in a ZATCA-compliant way, across six candidate cases, and how each is built on Invora using REST (gRPC-JSON transcoding).
Basis: ZATCA E-Invoicing Phase 2 (Integration); VAT Implementing Regulations (VAT IR) as amended April 2025.
Sources: Every regulatory statement maps to a primary-source file and an article/section locator in regulations/SOURCES.md.

Not legal or tax advice

Technical and regulatory reference only. Confirm the classification questions in §10 with a qualified KSA VAT adviser before implementation.

Contents¶

Parties and the two invoice legs
Summary of constraints
Assumptions and VAT permutations
Regulatory rules that shape the design
The Invora platform model
The cases
Permutation matrix
Decision framework
Implementation notes
Open questions for the legal and tax team
References

1. Parties and the two invoice legs¶

Symbol	Party	Role
SP	Service Provider	Performs the service.
P	Platform (the startup)	Intermediary that organises the transaction and charges a per-transaction fee.
C	Customer	Recipient of the service. A consumer in most cases; sometimes a business.

Each transaction produces up to two e-invoices:

Invoice 1 is the customer-facing supply: the seller of record bills C.
Invoice 2 is the inter-party invoice between P and SP.

The seller, buyer and issuer of each invoice, and what each invoice represents, change with the case. Invoice 2 is the platform fee in some cases and SP's service cost to P in others, and its issuer and aggregation vary too. The first three cases set the two legal positions (who supplies C); Cases 4 to 6 are issuance and aggregation variants of them.

Case	Invoice 1: seller, buyer (issuer)	Invoice 1 represents	Invoice 2: seller, buyer (issuer)	Invoice 2 represents
Case 1	SP to C (issuer SP)	SP's service to C	P to SP (issuer P)	Platform fee (P's commission)
Case 2	P to C (issuer P)	P's resold service to C	SP to P (issuer P, self-billed)	SP's service cost to P; fee is P's margin
Case 3	SP to C (issuer P, third-party)	SP's service to C	P to SP (issuer P)	Platform fee (P's commission)
Case 4	P to C (issuer P)	P's resold service to C	SP to P (issuer SP)	SP's service cost to P; fee is P's margin
Case 5	SP to C (issuer SP or P)	SP's service to C	P to SP (issuer SP, self-billed)	Platform commission
Case 6	per parent case	service to C	P to SP (issuer P, monthly summary)	Aggregated platform fees

flowchart LR
  SP["Service Provider (SP)"] -- "performs the service" --> C["Customer (C)"]
  P["Platform (P)"] -- "organises / facilitates" --> SP
  P -- "organises / facilitates" --> C

"Issuer" means the party that generates, signs and submits the e-invoice to ZATCA. It is distinct from the seller. ZATCA treats the seller (AccountingSupplierParty) as the legally responsible supplier regardless of who issues the document. That separation is what Cases 2 and 3 rely on.

2. Summary of constraints¶

All six cases are expressible on Invora and each has a basis in ZATCA/VAT rules. They are not interchangeable: which one is lawful for a given transaction depends on who the real supplier to C is, and on the deemed-supplier rule below.
The deemed-supplier gate. VAT IR Article 47(3), the electronic-marketplace "deemed-supplier" rule, took effect 1 January 2026. When a marketplace facilitates a supply for (A) a non-resident supplier or (B) a non-registered-resident supplier, the marketplace is treated as the supplier to the customer and must report and remit the VAT, unless a narrow exception applies (it does not set terms, set the price, collect payment, handle complaints, or run promotions). A platform that collects payment and sets terms does not meet the exception. See §4.6. Consequence: for non-registered or non-resident SPs, the law forces the Case 2 shape regardless of commercial preference.
For VAT-registered resident SPs the gate does not apply, and the choice among the cases becomes a VAT-agency and operational decision:
Case 1 maps to the disclosed-agent case: SP is the supplier to C; P sells only an agency service. Lowest classification risk; issuance effort distributed across SPs.
Case 3 is the same VAT position as Case 1 but uses third-party invoicing (VAT IR Art. 53(3)): SP stays the supplier of record and keeps the output-tax liability; P operates the issuance. Best operational ergonomics while keeping SP as supplier.
Case 2 maps to the undisclosed-agent (commissionaire) case: P is the supplier to C, and the SP→P leg becomes a self-billed invoice (VAT IR Art. 53(2)). Strongest platform control; largest VAT footprint for P, and self-billing carries strict conditions.
Cases 4 to 6 keep these VAT positions but vary issuance and aggregation: Case 4 is the principal model with SP invoicing P normally (no self-billing), Case 5 self-bills the commission, and Case 6 issues one monthly summary fee invoice per SP.
Invora surfaces. SPs onboard as Connected Businesses (POST /api/v2/identity/connected-businesses). The Simple surface (/api/v1/simple/invoices) is the path where the seller is the issuing tenant. The full UBL documents/v2 surface (/api/v2/documents, including the SelfBilledInvoice type and raw xmlContent) is the path where the seller differs from the issuer and where the third-party or self-billed InvoiceTypeCode flags are set.

3. Assumptions and VAT permutations¶

The analysis covers the full permutation space:

Dimension	Permutations
Customer (C)	Non-registered consumer → simplified invoice, reporting model. VAT-registered business → standard tax invoice, clearance model.
Service Provider (SP)	VAT-registered resident → standard invoices, clearance. Non-registered (below threshold) or non-resident → triggers the deemed-supplier gate and changes self-billing eligibility.
Platform (P)	VAT-registered resident taxable person. P must be registered to charge VAT on its fees and to operate as an issuer in KSA.

Working assumptions (flag any that are wrong, see §10):

Transactions are in SAR; supplies are standard-rated at 15% unless a specific zero-rating or exemption applies.
P is onboarded to ZATCA Phase 2 with a production CSID and acts as the issuing solution for the flows it generates.
The per-transaction platform fee is a taxable supply of intermediation services by P.

4. Regulatory rules that shape the design¶

Each rule below maps to a primary source. Canonical URLs and per-claim locators are in regulations/SOURCES.md.

4.1 Two invoice types, two submission models¶

ZATCA Phase 2 handles Standard Tax Invoices (B2B) and Simplified Tax Invoices (B2C) differently.

Clearance applies to Standard Tax Invoices. ZATCA verifies the invoice and inserts the cryptographic stamp before it is valid to give to the buyer (blocking). Clearance does not apply to simplified invoices. (Detailed Guideline §2.15.)
Reporting applies to Simplified Tax Invoices. The issuer transmits them to the FATOORA Portal within 24 hours of issuance (async, non-blocking). (Detailed Guideline §2.16.)

For the cases below: Invoice 1 to a consumer is a simplified invoice (reporting). Invoice 1 to a business, and every platform-fee invoice (B2B), is a standard invoice (clearance). This drives latency and failure handling in every flow.

4.2 Who is the supplier: disclosed vs undisclosed agent¶

Because P is an intermediary, the threshold question is whether P acts as a disclosed agent (SP is the supplier to C) or an undisclosed agent / commissionaire (P is the supplier to C). The VAT Agents Guideline defines both.

A disclosed agent acts for a principal where the agency relationship is disclosed to the third party. The principal (SP) is the supplier; the agent (P) supplies only an agency service (its fee).
An undisclosed agent acts in its own name and does not disclose that it acts for a principal. The guideline calls this a "commissionaire" and provides that the agent "is treated as a Principal for VAT purposes" (§6.2). P is then treated as buying the service from SP and re-supplying it to C.

Cases 1 and 3 are disclosed-agent structures. Case 2 is an undisclosed-agent structure. The classification depends on the actual contracts, branding, and who the customer understands they are buying from. It is a legal determination, not an engineering one.

4.3 Third-party invoicing (VAT IR Art. 53(3))¶

A third party may issue a tax invoice on behalf of the supplier. The supplier stays the supplier of record and keeps the liability:

"Subject to the Authority's approval, a Taxable Person may issue Tax Invoices through a third-party provided that all obligations … set forth in the Law and these Regulations are satisfied. The Supplier shall be responsible for the accuracy of the information shown on the Tax Invoice and for reporting Output Tax on the supply." — VAT IR Article 53(3).

ZATCA's e-invoicing scope confirms the third party is itself an in-scope issuer (Detailed Guideline §1.5). This is the basis for Case 3: P issues Invoice 1, SP remains the AccountingSupplierParty, and the document carries the third-party flag.

4.4 Self-billing (VAT IR Art. 53(2))¶

The customer may issue the tax invoice on behalf of the supplier (self-billing), under four conditions:

"Subject to the Authority's approval, a Taxable Customer may issue Tax Invoices on behalf of a Supply made by a Taxable Supplier provided that a prior agreement between such Supplier and Customer has been made to this effect; that the Tax Invoice state that it was issued by the Customer on behalf of the Supplier; and that the Supplier and Customer are registered with the Authority for VAT purposes. … a certification by the Supplier that they will not issue invoices in respect of the Supplies for those Tax Invoices were issued." — VAT IR Article 53(2).

So self-billing requires: (1) a prior agreement; (2) the invoice states it is self-billed; (3) both parties VAT-registered; (4) the supplier certifies it will not also issue its own invoice. The XML Implementation Standard adds that self-billing is B2B-only and is not permitted for exports. This is the basis for Invoice 2 of Case 2: P, as the customer of SP's supply, issues a self-billed invoice, but only when both SP and P are VAT-registered.

4.5 The `InvoiceTypeCode @name` transaction flags¶

ZATCA encodes the invoice subtype and transaction flags in the UBL cbc:InvoiceTypeCode/@name attribute as a seven-character string NNPNESB (rule BR-KSA-06).

Position	Meaning	Values
1–2 (`NN`)	Invoice subtype	`01` standard tax invoice, `02` simplified tax invoice
3 (`P`)	Third-party transaction	0 / 1
4 (`N`)	Nominal transaction	0 / 1
5 (`E`)	Exports transaction	0 / 1
6 (`S`)	Summary transaction	0 / 1
7 (`B`)	Self-billed transaction	0 / 1 (cannot be 1 when position 5 = 1)

ZATCA's official sample documents (in regulations/zatca-sample-documents/, indexed in SOURCES.md) use these values:

Sample	`@name`	Meaning
`standard-b2b-tax-invoice.xml`	`0100000`	standard, no flags
`simplified-b2c-invoice.xml`	`0200000`	simplified, no flags
`third-party-billing.xml`	`0110000`	standard + third-party (pos 3)
`self-billing-invoice.xml`	`0100001`	standard + self-billed (pos 7)
`summary-invoice.xml`	`0100010`	standard + summary (pos 6)

In both the third-party and self-billed samples, the AccountingSupplierParty is the actual seller. The flag, not the supplier party, signals third-party or self-billed issuance. A simplified third-party invoice (Case 3 to a consumer) uses 0210000 (subtype 02 plus position-3 flag), derived from BR-KSA-06; ZATCA's sample set ships only the standard third-party form 0110000.

4.6 Deemed-supplier rule (VAT IR Art. 47(3))¶

KSA amended the VAT IR (Official Gazette 18 April 2025). Most changes took effect on 18 April 2025; the electronic-marketplace deemed-supplier provision (Article 47, Paragraph 3) took effect on 1 January 2026.

When a marketplace acts as an intermediary for a non-resident supplier (Scenario A) or a non-registered-resident supplier (Scenario B), it is treated as having acquired and supplied the service on its own account, and is the deemed supplier responsible for reporting and remitting the VAT. The marketplace is not deemed the supplier only if the agreement names the real supplier as principal and the marketplace does not do any of: set the terms of the supply, determine the consideration, collect payment from customers, handle customer complaints, or offer promotions or compensation.

flowchart TD
  A{"Is SP a VAT-registered resident?"} -->|Yes| B["Deemed-supplier rule does not apply.<br/>Free choice among Cases 1 / 2 / 3<br/>on VAT-agency and operational grounds."]
  A -->|"No (non-resident or non-registered resident)"| C{"Does the platform avoid ALL of:<br/>setting terms, setting price, collecting payment,<br/>handling complaints, running promotions?"}
  C -->|"Yes (exception met)"| D["Marketplace not deemed supplier.<br/>SP still cannot issue standard tax invoices<br/>or self-bill if it is unregistered."]
  C -->|"No (platform controls payment/terms)"| E["Platform is the deemed supplier.<br/>Use the Case 2 shape: P is the supplier to C<br/>and reports/remits the service VAT."]

For a payment-collecting, terms-setting platform, any SP that is non-resident or not VAT-registered puts the platform in the deemed-supplier position, and the Case 2 shape becomes mandatory for those transactions. For VAT-registered resident SPs, Cases 1, 2 and 3 (and their variants 4 to 6) all remain available.

5. The Invora platform model¶

REST paths and JSON field names below follow Invora's gRPC-JSON transcoding contract. Paths come from each RPC's google.api.http annotation; JSON bodies use camelCase field names (proto freeze_immediately becomes freezeImmediately).

5.1 Organisation types¶

Invora has three organisation types: Business, Platform, and Connected Business. A Connected Business is a sub-tenant created and managed by a Platform; it is a fully separate tenant with its own users, invoices, documents and CSID, and its usage rolls up to the parent's billing. P upgrades to Platform through platform enrollment, then creates each SP as a Connected Business.

flowchart TD
  P["Platform tenant: P<br/>(own self-party, branches, CSID)"]
  P --> SP1["Connected Business: SP #1<br/>(own tenant, self-party, CSID)"]
  P --> SP2["Connected Business: SP #2<br/>(own tenant, self-party, CSID)"]
  P -. "Customers (C) are parties, not tenants" .-> Parties[(Stored parties / inline buyers)]

5.2 The two invoicing surfaces¶

The seller-equals-issuer decision is made by choosing a surface.

Surface	REST base	Seller is	Sets third-party / self-billed flag	Use for
Simple	`POST /api/v1/simple/invoices` (+ `/credit-notes`, `/debit-notes`)	The issuing tenant (its self-party / branch)	No	Legs where the seller is the tenant issuing the document (Case 1 both legs; Case 2 Invoice 1; Case 3 Invoice 2).
Full UBL `documents/v2`	`POST /api/v2/documents`	Explicit (the supplied UBL `AccountingSupplierParty`, or raw `xmlContent`)	Yes (`content.selfBilledInvoice` or the `InvoiceTypeCode/@name` flags in `xmlContent`)	Legs where the seller differs from the issuer or a subtype flag is required (Case 2 Invoice 2; Case 3 Invoice 1).

The documents/v2 CreateRequest:

POST /api/v2/documents
{
  "changes": {
    // typed UBL …
    "content": { "invoice": { /* UBL InvoiceType */ } }
    // … or a self-billed document:
    // "content": { "selfBilledInvoice": { /* UBL SelfBilledInvoiceType */ } }
    // … or raw UBL XML (the direct way to set the @name flags):
    // "xmlContent": "<Invoice …><cbc:InvoiceTypeCode name=\"0110000\">388</cbc:InvoiceTypeCode>…</Invoice>"
  },
  "freezeImmediately": true,   // create, sign, and submit to ZATCA in one call
  "autoCalculate": true,       // compute totals, taxes, and allowances
  "branchId": "branch_…"       // which branch (and therefore which CSID and numbering chain) issues it
}

Supporting calls: POST /api/v2/documents/calculate (preview totals), POST /api/v2/documents/{key}/validate, POST /api/v2/documents/{key}/freeze ({key, concurrencyStamp}), and GET /api/v2/documents/{key}.

5.3 Seller identity, branches and ZATCA onboarding¶

The seller for a tenant is its self-party: GET/PUT /api/v2/settings/self-party. Multi-establishment sellers use branches (POST /api/v2/branches), each carrying its own VAT number, CRN and CSID. The branchId on an invoice selects the issuing establishment and its numbering chain.
ZATCA onboarding runs per tenant or branch: POST /api/v1/regulations/zatca/onboarding (streams CSR, compliance CSID, production CSID), GET /api/v1/regulations/zatca/integration-status, and per-branch POST /api/v2/regulations/{regulationId}/enrollment/branches/{branchId}/begin. The branch's ZATCA settings (environment, VAT number, CRN, address) are held in the typed ZatcaConfig on the branch's RegulationConfig.
Submission status and artefacts for a frozen document: GET /api/v2/regulations/documents/{documentKey} (status, QR, hash, counter) and GET /api/v2/regulations/{regulationId}/documents/{documentKey}/artifact (signed XML and QR bytes).

5.4 Onboarding an SP as a Connected Business¶

This is the shared first step of Cases 1 and 3.

// P (Platform) creates the SP sub-tenant. The create body is name + adminEmail only.
POST /api/v2/identity/connected-businesses
{ "name": "Speedy Services LLC", "adminEmail": "admin@speedy.example" }
// → { "connectedBusiness": { "tenantId": "tnt_sp1", "parentTenantId": "tnt_p", "status": "…PROVISIONING" },
//     "clientId": "…", "clientSecret": "…" }   // M2M credentials for the SP tenant; returned once, store securely

Set the SP's tax identity inside the SP tenant after creation: PUT /api/v2/settings/self-party (legal name, VAT number, address), POST /api/v2/branches for each establishment, then run ZATCA onboarding so the SP receives its own production CSID. P drives these calls machine-to-machine using the SP's clientId/clientSecret (or the platform Impersonation service).

5.5 Producing the platform-fee invoice¶

The platform-fee invoice (Cases 1 and 3, Invoice 2) is a per-transaction P→SP standard tax invoice. There are two ways to produce it:

As a per-transaction e-invoice on the invoicing surface (/api/v1/simple/invoices or /api/v2/documents). Fits a genuinely per-transaction fee with one tax invoice per service event.
Through the Billing module (/api/billing/v2/*): meter each transaction as a usage event (POST /api/billing/v2/events), let a plan/subscription aggregate and generate the invoice, which Invora converts into a UBL document and submits to ZATCA. Fits aggregated or periodic fees, or when you want dunning, wallets, and payment collection.

The case flows use option 1, since the fee here is per-transaction. See §9 for the trade-off.

6. The cases¶

Each case below gives the party tables for both invoices, the regulatory basis, the deemed-supplier verdict, a REST flow, and a pros/cons table split into regulation-side and Invora-side. Flows assume P and the relevant SP are already onboarded to ZATCA Phase 2.

6.1 Case 1 — SP is the supplier and self-issues; P bills SP a fee¶

SP supplies the service to C and issues its own invoice (disclosed-agent structure). P supplies an agency service to SP and issues a separate fee invoice.

	Seller (`AccountingSupplierParty`)	Buyer (`AccountingCustomerParty`)	Issuer	Subtype
Invoice 1 — SP's service to C	SP	C	SP (own tenant)	C consumer → simplified `0200000` (reporting); C business → standard `0100000` (clearance)
Invoice 2 — platform fee	P	SP	P (own tenant)	standard `0100000` (clearance, B2B)

Regulatory basis. Ordinary invoicing; no third-party or self-billing mechanism. SP is the supplier to C (disclosed agent, §4.2); P's fee is a normal B2B supply.

Deemed-supplier verdict. Available only when SP is a VAT-registered resident. If SP is non-resident or non-registered, it cannot issue a valid KSA tax invoice and the deemed-supplier rule (§4.6) moves the supply onto P, so Case 1 is not available; use Case 2.

REST flow.

// Invoice 1: SP issues the service invoice in its own tenant.
// (a) C is a consumer → simplified, reporting:
POST /api/v1/simple/invoices            // Authorization: Bearer <SP-tenant token>
{
  "freezeImmediately": true,
  "changes": {
    "issueAt": "2026-06-12T09:00:00Z",
    "supplyDate": { "year": 2026, "month": 6, "day": 12 },
    "currencyCode": "SAR",
    "buyer": { "inline": { "legalName": "Walk-in Customer" } },   // no vatRegistrationNumber → simplified / B2C
    "lines": [ { "description": "Home cleaning visit",
                 "quantity": { "value": {"units":"1","nanos":0}, "unitCode": "HUR" },
                 "unitPrice": { "units": "200", "nanos": 0 }, "tax": { "taxRate": { "units": "15", "nanos": 0 } } } ]
  }
}
// → SimpleInvoice with calculations and ZatcaRegulationMetadata (status REPORTED, QR). B2C reports asynchronously, within 24h.
// (b) C is a business → add buyer.inline.vatRegistrationNumber → standard invoice, cleared before it is valid.

// Invoice 2: P issues the platform-fee invoice in P's tenant, buyer = SP.
POST /api/v1/simple/invoices            // Authorization: Bearer <P-tenant token>
{
  "freezeImmediately": true,
  "changes": {
    "issueAt": "2026-06-12T09:05:00Z",
    "supplyDate": { "year": 2026, "month": 6, "day": 12 },
    "currencyCode": "SAR",
    "buyer": { "inline": { "legalName": "Speedy Services LLC", "vatRegistrationNumber": "3XXXXXXXXXXXXX3",
                            "address": { "buildingNumber": "1234", "streetName": "…", "cityName": "Riyadh",
                                         "postalZone": "12345", "countryCode": "SA" } } },
    "lines": [ { "description": "Platform fee — transaction INV-… (10%)",
                 "quantity": { "value": {"units":"1","nanos":0}, "unitCode": "C62" },
                 "unitPrice": { "units": "20", "nanos": 0 }, "tax": { "taxRate": { "units": "15", "nanos": 0 } } } ]
  }
}
// → standard tax invoice, cleared before it is valid to hand to SP.

Pros and cons.

	Pros	Cons
Regulation-side	Simplest VAT position: each party invoices its own supply; no Authority pre-approval for third-party or self-billing. SP carries its own output tax; P carries only fee VAT. One supplier per invoice keeps the audit trail clean.	Requires every SP to be a VAT-registered resident and a working ZATCA issuer. Fails for unregistered or non-resident SPs. Disclosed agency must be genuine (contracts and branding show SP as the seller to C).
Invora-side	Uses the Simple surface end to end (lowest integration effort); no `xmlContent` or flags. Each SP is an isolated Connected Business with its own CSID and numbering.	P onboards every SP to ZATCA and operates issuance inside each SP tenant; many tenants to provision and monitor. Two `freezeImmediately` calls in two tenants per transaction.

6.2 Case 2 — P is the supplier to C; P self-bills SP for the service¶

P is the supplier to C (undisclosed-agent / commissionaire structure, or deemed supplier by law). SP supplies its service to P, and because P is the customer of that supply, P issues a self-billed invoice on SP's behalf.

	Seller (`AccountingSupplierParty`)	Buyer (`AccountingCustomerParty`)	Issuer	Subtype
Invoice 1 — P's resold service to C	P	C	P (own tenant)	C consumer → simplified `0200000` (reporting); C business → standard `0100000` (clearance)
Invoice 2 — SP's service supply to P (self-billed)	SP	P	P (the customer, self-billing)	standard self-billed `0100001` (clearance, B2B only)

Invoice 2 here is not the platform fee. It is SP's supply to P. In the commissionaire structure the platform fee is P's retained margin: (Invoice 1 value, P→C) minus (Invoice 2 value, SP→P). If you also want an explicit fee invoice P→SP, that is an additional standard invoice as in Case 1, but do not double-count the same economics. Confirm the intended expression with the finance and legal team (§10).

Regulatory basis. P as supplier to C is the undisclosed agent treated as principal (§4.2), or the deemed supplier under Art. 47(3) when SP is non-resident or non-registered (§4.6). The SP→P self-billed leg relies on VAT IR Art. 53(2) (§4.4) and is valid only when both SP and P are VAT-registered, a prior self-billing agreement exists, the invoice states it is self-billed, and SP certifies it will not also invoice P.

Deemed-supplier verdict. This is the shape the law requires when P is a deemed supplier (non-resident or non-registered SP and P controls payment or terms). Caveat: if SP is non-registered, the self-billed Invoice 2 is not available (Art. 53(2) needs both parties registered). In that sub-case there is no SP→P tax invoice; SP's supply to P is out of scope (unregistered resident) or a reverse-charge import of services that P self-accounts for (non-resident SP). Only Invoice 1 (P→C) is a ZATCA e-invoice.

REST flow.

// Invoice 1: P is the supplier to C (P's tenant, Simple surface).
POST /api/v1/simple/invoices            // Authorization: Bearer <P-tenant token>
{ "freezeImmediately": true,
  "changes": { "issueAt": "2026-06-12T09:00:00Z", "supplyDate": {"year":2026,"month":6,"day":12},
    "currencyCode": "SAR",
    "buyer": { "inline": { "legalName": "Walk-in Customer" } },     // consumer → simplified; add vatRegistrationNumber for B2B
    "lines": [ { "description": "Home cleaning visit", "quantity": {"value":{"units":"1","nanos":0},"unitCode":"HUR"},
                 "unitPrice": {"units":"200","nanos":0}, "tax": {"taxRate":{"units":"15","nanos":0}} } ] } }

// Invoice 2: P self-bills SP (seller = SP, buyer = P). The documents/v2 surface sets seller ≠ issuer
// and the self-billed flag. Use xmlContent (name="0100001") or content.selfBilledInvoice.
POST /api/v2/documents                  // Authorization: Bearer <P-tenant token>
{ "freezeImmediately": true, "autoCalculate": true,
  "changes": {
    "xmlContent": "<Invoice …>\n  <cbc:InvoiceTypeCode name=\"0100001\">388</cbc:InvoiceTypeCode>\n  <!-- AccountingSupplierParty = SP (VAT-registered) -->\n  <!-- AccountingCustomerParty = P -->\n  <!-- a note stating the invoice is self-billed (Art. 53(2)) -->\n</Invoice>"
  }
}
// Equivalent: "changes": { "content": { "selfBilledInvoice": { /* SelfBilledInvoiceType, supplier=SP, customer=P */ } } }
// → standard self-billed tax invoice, cleared. Reference: regulations/zatca-sample-documents/self-billing-invoice.xml (name="0100001").

For Cases 2 and 3, the legal supplier is fixed by the document (SP for the self-billed leg, SP for the third-party leg). Which tenant or CSID signs the document, and how the numbering chain is attributed, is an Invora backend behaviour. Confirm the cross-tenant signing and counter model with the Invora team before go-live.

Pros and cons.

	Pros	Cons
Regulation-side	The only lawful shape when P is a deemed supplier (non-resident or non-registered SPs). One supplier of record to C (P) simplifies customer-side disputes. Self-billing removes the need for many small SPs to operate ZATCA.	P carries the full service output VAT, not just fee VAT (larger VAT cash-flow and exposure). Self-billing has four conditions (Art. 53(2)): prior agreement, both registered, no duplication, stated self-billed; it is invalid the moment an SP is unregistered, is B2B only, and is barred for exports. Misclassifying a disclosed arrangement as commissionaire is a VAT risk.
Invora-side	SPs need no ZATCA onboarding; P issues everything from P's tenant. Fewer issuing tenants. Invora has a first-class `SelfBilledInvoice` document type.	Requires the full UBL `documents/v2` surface and `xmlContent` or typed self-billed content (more integration effort than Simple). The self-billing agreement lifecycle is managed out of band. Cross-tenant signing and counter behaviour needs validation.

6.3 Case 3 — SP is the supplier, P issues on SP's behalf (third-party)¶

Same VAT position as Case 1 (SP is the supplier to C), but P issues Invoice 1 on SP's behalf through third-party invoicing. SP stays the supplier of record and keeps the data and output-tax responsibility.

	Seller (`AccountingSupplierParty`)	Buyer (`AccountingCustomerParty`)	Issuer	Subtype
Invoice 1 — SP's service to C	SP	C	P (third party)	C consumer → simplified third-party `0210000` (reporting); C business → standard third-party `0110000` (clearance)
Invoice 2 — platform fee	P	SP	P (own tenant)	standard `0100000` (clearance, B2B)

Regulatory basis. VAT IR Art. 53(3) (§4.3): a taxable person may issue tax invoices through a third party, and the supplier remains responsible for accuracy and for reporting output tax. The invoice carries the third-party flag (@name position 3 = 1). ZATCA's third-party-billing.xml sample keeps the AccountingSupplierParty as SP, not P.

Deemed-supplier verdict. Available only when SP is a VAT-registered resident, the same gate as Case 1. If SP is non-resident or non-registered, the deemed-supplier rule forces the Case 2 shape; third-party issuance cannot make an invalid supplier into a valid one.

REST flow.

// Invoice 1: P issues a third-party invoice where the supplier is SP. Use documents/v2 with xmlContent
// carrying name="0110000" (B2B) or "0210000" (B2C), AccountingSupplierParty = SP, AccountingCustomerParty = C.
// Issue within the SP context so SP's CSID and numbering chain apply (see note in 6.2).
POST /api/v2/documents                  // Authorization: Bearer <SP-tenant token, driven M2M by P>
{ "freezeImmediately": true, "autoCalculate": true, "branchId": "<SP branch>",
  "changes": {
    "xmlContent": "<Invoice …>\n  <cbc:InvoiceTypeCode name=\"0110000\">388</cbc:InvoiceTypeCode>\n  <!-- AccountingSupplierParty = SP (the real seller) -->\n  <!-- AccountingCustomerParty = C -->\n</Invoice>"
  }
}
// → third-party standard tax invoice, supplier = SP, cleared. For a consumer C use name="0210000" (simplified, reporting).
// Reference: regulations/zatca-sample-documents/third-party-billing.xml (name="0110000", supplier unchanged).

// Invoice 2 (platform fee, P → SP): identical to Case 1's Invoice 2 (P's tenant, Simple surface, buyer = SP, standard).
POST /api/v1/simple/invoices            // Authorization: Bearer <P-tenant token>
{ "freezeImmediately": true, "changes": { "…": "buyer = SP, line = platform fee, 15% VAT" } }

Third-party issuance means P operates the issuance while SP is the supplier of record. The two options are: (a) P drives the SP's tenant through the SP's M2M credentials or the Impersonation service, so SP's production CSID signs and SP's numbering chain advances (keeps the chain with the supplier); or (b) P issues from P's own solution as a registered third party. Confirm which signing and CSID model Invora applies before go-live.

Pros and cons.

	Pros	Cons
Regulation-side	Same clean VAT position as Case 1 (SP is supplier; P carries only fee VAT), with the issuance burden centralised on P. Sanctioned by Art. 53(3). SP stays responsible for accuracy and output tax (clear liability line). Works for both B2C (third-party simplified) and B2B (third-party standard).	Requires SP to be a VAT-registered resident (no help for unregistered or non-resident SPs). Third-party issuance needs Authority approval and correct flagging; SP remains liable for errors P makes. Disclosed agency must be genuine.
Invora-side	P centralises the integration (one issuing pipeline) while keeping SP as supplier; the best operational ergonomics of the three for a platform that wants control without becoming the supplier. Uses `documents/v2` plus the third-party `@name` flag, with ZATCA's sample as a template.	Still onboards each SP to ZATCA (SP needs a CSID as supplier of record) and builds the `documents/v2` `xmlContent` path; the most moving parts of the three. Cross-tenant third-party signing and CSID attribution needs validation.

6.4 Case 4 — P is the supplier to C; SP invoices P normally (principal without self-billing)¶

Same supplier position as Case 2 (P is the supplier to C), but the inter-party leg is an ordinary tax invoice issued by SP, not a self-billed invoice issued by P. This is the default reseller/principal setup when SP is a VAT-registered issuer.

	Seller (`AccountingSupplierParty`)	Buyer (`AccountingCustomerParty`)	Issuer	Subtype
Invoice 1 — P's resold service to C	P	C	P (own tenant)	C consumer → simplified `0200000` (reporting); C business → standard `0100000` (clearance)
Invoice 2 — SP's service supply to P	SP	P	SP (own tenant)	standard `0100000` (clearance, B2B)

Invoice 2 here is SP's supply to P, the same economics as Case 2's Invoice 2, but issued by SP under ordinary invoicing rather than self-billed by P. The platform fee remains P's retained margin: (Invoice 1, P→C) minus (Invoice 2, SP→P).

Regulatory basis. P as supplier to C is the undisclosed agent treated as principal, or the deemed supplier under Art. 47(3) (§4.2, §4.6). Invoice 2 is an ordinary tax invoice from SP to P (VAT IR Art. 53(1)). Unlike Case 2, no self-billing agreement or Authority approval is needed, but SP must be VAT-registered to issue it.

Deemed-supplier verdict. This is the principal shape when SP is a VAT-registered resident. If SP is non-registered or non-resident it cannot issue Invoice 2, and the deemed-supplier rule still places the supply on P; the SP→P leg then becomes out of scope or a reverse-charge import, which is the Case 2 fallback. Choose Case 4 over Case 2 when SPs are registered and willing to invoice P; choose Case 2 when they are not.

REST flow.

// Invoice 1: P is the supplier to C (P's tenant, Simple surface) — identical to Case 2's Invoice 1.
POST /api/v1/simple/invoices            // Authorization: Bearer <P-tenant token>
{ "freezeImmediately": true,
  "changes": { "issueAt": "2026-06-12T09:00:00Z", "supplyDate": {"year":2026,"month":6,"day":12},
    "currencyCode": "SAR",
    "buyer": { "inline": { "legalName": "Walk-in Customer" } },     // consumer → simplified; add vatRegistrationNumber for B2B
    "lines": [ { "description": "Home cleaning visit", "quantity": {"value":{"units":"1","nanos":0},"unitCode":"HUR"},
                 "unitPrice": {"units":"200","nanos":0}, "tax": {"taxRate":{"units":"15","nanos":0}} } ] } }

// Invoice 2: SP issues its own tax invoice to P (SP's tenant, Simple surface, buyer = P, standard).
POST /api/v1/simple/invoices            // Authorization: Bearer <SP-tenant token>
{ "freezeImmediately": true,
  "changes": { "issueAt": "2026-06-12T09:05:00Z", "supplyDate": {"year":2026,"month":6,"day":12},
    "currencyCode": "SAR",
    "buyer": { "inline": { "legalName": "The Platform LLC", "vatRegistrationNumber": "3XXXXXXXXXXXXX3",
                            "address": { "buildingNumber": "100", "streetName": "…", "cityName": "Riyadh",
                                         "postalZone": "12345", "countryCode": "SA" } } },
    "lines": [ { "description": "Cleaning service supplied to platform — transaction INV-…",
                 "quantity": {"value":{"units":"1","nanos":0},"unitCode":"HUR"},
                 "unitPrice": {"units":"180","nanos":0}, "tax": {"taxRate":{"units":"15","nanos":0}} } ] } }
// → standard tax invoice, cleared. P deducts the input tax; P accounts for output tax on the full Invoice 1 to C.

Pros and cons.

	Pros	Cons
Regulation-side	Simplest principal model: ordinary invoicing on both legs, no self-billing agreement or Authority approval. SP carries its own output tax on the SP→P supply; P deducts it as input tax. One supplier per invoice.	P still carries the full service output VAT to C (principal exposure). Requires SP to be a VAT-registered resident. Misclassifying a disclosed arrangement as principal is a VAT risk, the same caveat as Case 2.
Invora-side	Both legs use the Simple surface; no `xmlContent` or flags. SP issues from its own tenant.	Each SP must be ZATCA-onboarded as an issuer (same as Cases 1 and 3). Two `freezeImmediately` calls in two tenants per transaction. P depends on SPs to issue Invoice 2 on time.

6.5 Case 5 — Disclosed agent; SP self-bills P for the commission¶

Same supplier position as Cases 1 and 3 (SP is the supplier to C), but the platform fee is self-billed by SP instead of issued by P. P's commission is itself a taxable supply to SP, so SP, as the customer of that commission, may self-bill P under Art. 53(2).

	Seller (`AccountingSupplierParty`)	Buyer (`AccountingCustomerParty`)	Issuer	Subtype
Invoice 1 — SP's service to C	SP	C	SP (Case 1) or P third-party (Case 3)	C consumer → simplified; C business → standard
Invoice 2 — platform commission	P	SP	SP (the customer, self-billing)	standard self-billed `0100001` (clearance, B2B only)

Regulatory basis. Disclosed agent: SP is the supplier to C (§4.2). Invoice 1 follows Case 1 or Case 3. Invoice 2 applies VAT IR Art. 53(2) (§4.4) to the commission supply: SP (customer of the commission) issues a self-billed invoice on P's behalf. The same four conditions apply: prior agreement, both parties VAT-registered, the invoice states it is self-billed, and P certifies it will not also issue its own fee invoice.

Deemed-supplier verdict. Available only when SP is a VAT-registered resident (self-billing needs both parties registered, and SP must be a valid supplier of record for Invoice 1). Non-registered or non-resident SPs fall to Case 2.

REST flow.

// Invoice 1: as Case 1 (SP issues in its own tenant) or Case 3 (P issues third-party for SP). See those flows.

// Invoice 2: SP self-bills P for the commission (seller = P, buyer = SP, self-billed). SP's tenant, documents/v2.
POST /api/v2/documents                  // Authorization: Bearer <SP-tenant token>
{ "freezeImmediately": true, "autoCalculate": true,
  "changes": {
    "xmlContent": "<Invoice …>\n  <cbc:InvoiceTypeCode name=\"0100001\">388</cbc:InvoiceTypeCode>\n  <!-- AccountingSupplierParty = P (supplier of the commission) -->\n  <!-- AccountingCustomerParty = SP -->\n  <!-- a note stating the invoice is self-billed (Art. 53(2)) -->\n</Invoice>"
  }
}
// Equivalent: "changes": { "content": { "selfBilledInvoice": { /* SelfBilledInvoiceType, supplier=P, customer=SP */ } } }
// → standard self-billed commission invoice, cleared. Reference: regulations/zatca-sample-documents/self-billing-invoice.xml.

Pros and cons.

	Pros	Cons
Regulation-side	Clean disclosed-agent VAT position (SP is supplier; P carries only fee VAT), and P avoids issuing many small fee invoices because SP self-bills them. Useful at high SP volume.	Adds the four Art. 53(2) self-billing conditions to the fee leg: prior agreement, both registered, no duplication, stated self-billed, plus Authority approval. B2B only. Both Invoice 1 and the self-billed fee require SP to be onboarded.
Invora-side	The fee leg moves to the SP tenant and the `documents/v2` self-billed type. P operates fewer issuing flows.	Highest SP-side complexity: SP runs both the service invoice and the self-billed fee invoice. Cross-tenant signing and counter behaviour for the self-billed document needs validation, the same caveat as Case 2.

6.6 Case 6 — Periodic summary fee invoice¶

An aggregation variant that layers on the fee leg of Case 1, 3, or 4. Instead of one fee invoice per transaction, P issues a single monthly summary tax invoice to each SP, covering all that month's fees. Invoice 1 stays per transaction in the parent case.

	Seller (`AccountingSupplierParty`)	Buyer (`AccountingCustomerParty`)	Issuer	Subtype
Invoice 1 — per transaction	per parent case (Case 1/3/4)	C	per parent case	per parent case
Invoice 2 — monthly summary of platform fees	P	SP	P (own tenant)	standard summary `0100010` (clearance, B2B)

Regulatory basis. VAT IR Art. 53(4): a taxable person may issue a summary tax invoice that includes more than one separate supply to the same customer within a period not exceeding one calendar month, issued no later than the fifteenth day of the month following. The document carries the summary flag (@name position 6 = 1; sample value 0100010). This applies to the P→SP fee leg, where SP is the same customer across many transactions.

Deemed-supplier verdict. Independent of the deemed-supplier gate; it changes only how the fee leg is aggregated. It composes with whichever parent case is lawful for the SP (Case 1 or 3 for the disclosed model, Case 4 for the principal model). It does not apply to the self-billed fee leg of Case 5 without a separate self-billing arrangement covering summary invoices.

REST flow. Two options:

// Option A — Billing module: meter each transaction's fee as a usage event, then a monthly plan invoice.
POST /api/billing/v2/events            // one call per transaction
{ "transactionId": "txn-INV-…", "code": "platform_fee", "externalCustomerId": "sp1",
  "timestamp": "2026-06-12T09:05:00Z", "properties": { "amount": "20.00", "documentRef": "INV-…" } }
// At cycle close, Invora aggregates the events into one invoice and converts it to a UBL document for ZATCA.

// Option B — documents/v2: build one summary invoice for the month with the summary flag and one line per transaction.
POST /api/v2/documents                  // Authorization: Bearer <P-tenant token>
{ "freezeImmediately": true, "autoCalculate": true,
  "changes": {
    "xmlContent": "<Invoice …>\n  <cbc:InvoiceTypeCode name=\"0100010\">388</cbc:InvoiceTypeCode>\n  <!-- AccountingSupplierParty = P, AccountingCustomerParty = SP -->\n  <!-- one InvoiceLine per transaction fee, each referencing its source document -->\n</Invoice>"
  }
}
// → standard summary tax invoice, cleared. Reference: regulations/zatca-sample-documents/summary-invoice.xml (name="0100010").

Pros and cons.

	Pros	Cons
Regulation-side	One fee invoice per SP per month instead of thousands; fewer ZATCA submissions. Explicitly allowed by Art. 53(4).	Constrained to one calendar month and the same customer, and must be issued by the fifteenth of the following month. Each fee line should reference its source transaction for audit. Does not change the VAT position, only the document count.
Invora-side	Natural fit for the Billing module (events, plans, subscriptions) with automatic UBL conversion, or a single `documents/v2` summary document. Lowest document volume of any fee option.	Adds the Billing module or the `documents/v2` summary path on top of the parent case. Reconciliation between metered events and the summary invoice lines must be exact.

7. Permutation matrix¶

Which cases are lawful for each permutation. P is always a VAT-registered resident.

SP status	C type	Case 1 (SP self-issues)	Case 3 (P third-party for SP)	Case 2 (P is supplier, self-bills SP)
VAT-registered resident	Consumer (B2C)	Available — simplified, reporting	Available — third-party simplified `0210000`	Available — P→C simplified; SP→P self-billed `0100001`
VAT-registered resident	Business (B2B)	Available — standard, clearance	Available — third-party standard `0110000`	Available — P→C standard; SP→P self-billed
Non-registered resident	Consumer / Business	Not available — SP cannot issue a tax invoice	Not available — SP is not a valid supplier of record	Required by Art. 47(3) — P is deemed supplier. No self-billed SP→P invoice (Art. 53(2) needs both registered); SP's supply to P is out of scope
Non-resident	Consumer / Business	Not available — non-resident not required or able to issue a KSA tax invoice	Not available — same	Required by Art. 47(3) — P is deemed supplier. SP→P leg is a reverse-charge import P self-accounts for; no self-billed e-invoice

When all SPs are VAT-registered residents, the decision is a business choice among the cases. With unregistered or non-resident SPs, Art. 47(3) forces the Case 2 shape for those transactions, and the SP→P leg is handled as out of scope or reverse charge rather than a self-billed invoice. A platform with a mixed SP base typically runs Case 1 or 3 for registered SPs and Case 2 for the rest; Invora supports both concurrently across tenants. Cases 4 to 6 attach to the registered-resident rows: Case 4 (principal, SP invoices P) and Case 5 (self-billed commission) need a VAT-registered resident SP; Case 6 (summary fee) layers on the fee leg of Case 1, 3, or 4 for any registered SP.

8. Decision framework¶

This section compares the cases and lists the factors that point to each one. It does not pick a case; the classification, especially disclosed vs undisclosed agency, is a legal and tax determination.

8.1 Comparison¶

Each case is summarised by the attributes that usually drive the choice.

Case	Supplier to C	Inter-party (fee) leg	Needs registered SP	P's VAT exposure	Invora surface	Best when
1	SP	P to SP, issued by P	Yes	Fee only	Simple	SPs registered; lowest integration effort
2	P	SP to P, self-billed by P	No (covers unregistered)	Full service	documents/v2	deemed-supplier, or unregistered/non-resident SPs
3	SP	P to SP, issued by P	Yes	Fee only	documents/v2 (Invoice 1)	SP is supplier but P centralises issuance
4	P	SP to P, issued by SP	Yes	Full service	Simple	principal model with registered SPs
5	SP	P to SP, self-billed by SP	Yes	Fee only	documents/v2 (fee)	disclosed model; push fee issuance to SP at volume
6	per parent	P to SP, monthly summary	per parent	per parent	Billing or summary document	cut fee document volume

8.2 Which case fits which situation¶

Case 1 fits when SPs are all VAT-registered residents, willing to act as their own supplier of record, and you want the lowest classification risk and lowest integration effort (Simple surface only).
Case 3 fits when SPs are VAT-registered residents but you want to centralise the issuing pipeline on P while keeping SP as the legal supplier: the disclosed-agent position of Case 1 with operational control closer to Case 2.
Case 2 is required when you onboard non-resident or non-registered SPs (the deemed-supplier rule makes it mandatory), or when P genuinely acts as an undisclosed principal reselling the service to C. It carries the largest VAT footprint and the strict self-billing conditions.
Case 4 fits the principal model when SPs are registered and will invoice P themselves: like Case 2 without the self-billing agreement.
Case 5 fits a disclosed model at high SP volume, pushing fee-invoice issuance onto SPs through self-billing.
Case 6 fits any per-transaction fee leg you want to collapse into one monthly invoice per SP.
A hybrid is the common outcome: Case 1 or 3 for registered-resident SPs, Case 2 for the SPs the deemed-supplier rule captures.

8.3 The two decisions that drive the choice¶

flowchart TD
  Q1{"Is the agency relationship disclosed to C?"}
  Q1 -->|"Yes: SP is the supplier to C"| Q2{"Who issues Invoice 1?"}
  Q1 -->|"No: P is the supplier to C"| Q3{"Who issues the SP-to-P leg?"}
  Q2 -->|"SP issues"| C1["Case 1"]
  Q2 -->|"P issues (third-party)"| C3["Case 3"]
  Q3 -->|"P self-bills SP"| C2["Case 2"]
  Q3 -->|"SP invoices P normally"| C4["Case 4"]
  Q1 -.->|"Gate: SP non-resident or non-registered forces Case 2"| G["Art. 47(3) deemed supplier"]

Two refinements layer on top: in the disclosed branch, SP can self-bill P's commission instead of P issuing the fee (Case 5); and any per-transaction P-to-SP fee leg (Cases 1, 3, 4) can be aggregated into one monthly summary invoice (Case 6).

9. Implementation notes¶

Platform-fee modelling. The flows issue Invoice 2 as a per-transaction tax invoice. To aggregate fees (monthly statement, wallets, dunning), use the Billing module: meter each event with POST /api/billing/v2/events, attach a plan or subscription, and Invora generates the billing invoice and converts it into a UBL document for ZATCA. Model each fee with one source of truth, not both.
B2C latency vs B2B blocking. Simplified invoices (consumer C) report asynchronously and are valid immediately, transmitted within 24 hours. Standard invoices (business C, and all P→SP fee invoices) clear synchronously and are valid only after ZATCA returns cleared. Build the customer-facing flow around the async path and the SP-facing and fee flows around the blocking path.
Numbering and the ZATCA counter chain are per branch and CSID. ZatcaRegulationMetadata.invoiceCounterValue and previousInvoiceHash increase monotonically per branch. Keep each SP's issuance on that SP's branch chain. This is relevant to the cross-tenant signing question in Cases 2 and 3.
Idempotency. Pass your own key on Create (both Simple and documents/v2 accept it) so retries do not double-issue. For Billing events, transactionId is the idempotency key.
Read status after freeze. Poll GET /api/v2/regulations/documents/{documentKey} for the authoritative ZatcaSubmissionStatus (CLEARED, REPORTED, NOT_CLEARED, FAILED) and fetch the signed XML or QR through GET /api/v2/regulations/{regulationId}/documents/{documentKey}/artifact.
Credit and debit notes inherit the leg. A correction is a credit or debit note with the same parties and the same subtype flag as the document it adjusts (Simple /credit-notes, /debit-notes, or documents/v2 creditNote / selfBilledCreditNote). The amended VAT IR sets a credit-note issuance deadline of 15 days from the end of the month of the triggering event.
Billing branding. External artefacts use the Invora Billing brand.

10. Open questions for the legal and tax team¶

Each of these changes the answer and is outside engineering's remit:

Disclosed vs undisclosed agency. Under the actual contracts, app UX, and payment flows, does C buy from SP (disclosed, Case 1 or 3) or from P (undisclosed principal, Case 2)? This is the primary fork.
Deemed-supplier scope (Art. 47(3)). Does the platform meet the electronic-marketplace definition, and does it fall within an exception (does it avoid setting terms, setting price, collecting payment, handling complaints, and promotions)? A payment-collecting platform generally does not meet the exception, so it is the deemed supplier for non-registered or non-resident SPs.
SP registration mix. Will the platform admit non-resident or non-VAT-registered SPs? If so, Case 2 is mandatory for them, with reverse-charge or out-of-scope handling of the SP→P leg.
Platform-fee expression in Case 2. Retained margin, or an explicit separate fee invoice? Avoid double counting.
Authority approvals. Third-party issuance (Art. 53(3)) and self-billing (Art. 53(2)) are subject to the Authority's approval and require documented agreements. Confirm the approvals and agreements before issuing in Cases 2 and 3.
Cross-tenant signing and CSID model in Invora for Cases 2 and 3 (which CSID signs, which counter chain advances). Confirm with the Invora team before go-live.

11. References¶

Primary-source files and per-claim locators are in regulations/SOURCES.md. Key mappings:

Statement	Source file	Locator
Clearance vs reporting (B2B/B2C)	`einvoicing-detailed-guideline-may2023.pdf`	§2.15, §2.16
Disclosed vs undisclosed agent	`vat-agents-guideline.pdf`	§4.2, §6.1–6.2
Third-party invoicing; supplier stays responsible	`vat-implementing-regulations-full-EN.pdf`	Art. 53(3)
Self-billing conditions	`vat-implementing-regulations-full-EN.pdf`	Art. 53(2)
`InvoiceTypeCode @name` flags (NNPNESB)	`zatca-sdk-official/…XML_Implementation_Standard_vF.pdf`	BR-KSA-06/07/08
Third-party and self-billed sample invoices	`zatca-sample-documents/third-party-billing.xml`, `self-billing-invoice.xml`	`@name` = `0110000` / `0100001`
Deemed-supplier rule, effective 1 Jan 2026	`vat-implementing-regulations-amended-apr2025-pwc.pdf`	Art. 47(3), pp. 2 & 4

Invora API paths and request fields correspond to the protobuf service definitions under clients/invora/invora-grpc/ and the generated OpenAPI surface.

Technical and regulatory reference. Not legal or tax advice. Confirm the questions in §10 with a qualified KSA VAT adviser before implementation.

ZATCA-Compliant Invoicing for an Intermediary Services Platform¶

Contents¶

1. Parties and the two invoice legs¶

2. Summary of constraints¶

3. Assumptions and VAT permutations¶

4. Regulatory rules that shape the design¶

4.1 Two invoice types, two submission models¶

4.2 Who is the supplier: disclosed vs undisclosed agent¶

4.3 Third-party invoicing (VAT IR Art. 53(3))¶

4.4 Self-billing (VAT IR Art. 53(2))¶

4.5 The InvoiceTypeCode @name transaction flags¶

4.6 Deemed-supplier rule (VAT IR Art. 47(3))¶

5. The Invora platform model¶

5.1 Organisation types¶

5.2 The two invoicing surfaces¶

5.3 Seller identity, branches and ZATCA onboarding¶

5.4 Onboarding an SP as a Connected Business¶

5.5 Producing the platform-fee invoice¶

6. The cases¶

6.1 Case 1 — SP is the supplier and self-issues; P bills SP a fee¶

6.2 Case 2 — P is the supplier to C; P self-bills SP for the service¶

6.3 Case 3 — SP is the supplier, P issues on SP's behalf (third-party)¶

6.4 Case 4 — P is the supplier to C; SP invoices P normally (principal without self-billing)¶

6.5 Case 5 — Disclosed agent; SP self-bills P for the commission¶

6.6 Case 6 — Periodic summary fee invoice¶

7. Permutation matrix¶

8. Decision framework¶

8.1 Comparison¶

8.2 Which case fits which situation¶

8.3 The two decisions that drive the choice¶

9. Implementation notes¶

10. Open questions for the legal and tax team¶

11. References¶

4.5 The `InvoiceTypeCode @name` transaction flags¶