--- title: "Document & invoice types" description: "Every document type Flowie sends — invoice, credit note, debit note, orders, quotes, events — plus every invoice subtype (prepayment, corrected, self-billed) and how self-billing and self-invoicing work." canonical: "https://docs.get-flowie.com/reference/document-types" source: "https://docs.get-flowie.com/reference/document-types.html" --- # Document & invoice types API Reference # Document & invoice types Every document you send flows through one endpoint — [`POST /v1/documents/send`]() — and a single `type` field tells Flowie what it is. This page is the complete referential: the eight [document types](<#document-types>), the four [invoice subtypes](<#invoice-subtypes>) (including **self-billed** invoices), and how the two flavours of _self-invoice_ — [self-billing](<#self-billing>) and [reverse-charge self-invoicing](<#self-invoice>) — differ and how to emit each. The one field that decides everything: `type` `type` is required on every send (except `event`, which needs no recipient). It picks the document class and the Peppol document type Flowie routes on. Invoice _sub_ -kinds (prepayment, corrected, self-billed) are a second, optional axis — [`documentSubtype`](<#invoice-subtypes>) — layered on top of `type: "invoice"`. ## Test any use case Every scenario on this page has a ready-to-send example body for [`POST /v1/documents/send`](). Expand one and hit **Try in Playground** — it opens the request builder prefilled with the payload, and the Playground loads your stored sandbox key automatically — or copy the JSON or a ready-made curl. Every example uses the sandbox test identifiers, so it runs as-is. Standard invoice 380 Ordinary sale of goods or services — the default. [code] { "type": "invoice", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0042", "issueDate": "2026-04-15", "currency": "EUR", "lines": [ { "description": "Consulting services", "quantity": 10, "unitPrice": 150.00, "vatRate": 21.0 } ] } } [/code] Multi-line invoice (mixed VAT rates) lines Several lines at different VAT rates — standard, reduced and an exempt intra-EU line carrying its reason. VAT is summed per rate. See [Multiple VAT rates](). [code] { "type": "invoice", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0500", "issueDate": "2026-04-15", "currency": "EUR", "lines": [ { "description": "Consulting (standard rate)", "quantity": 10, "unit": "HUR", "unitPrice": 150.00, "vatRate": 21.0, "vatCategory": "S" }, { "description": "E-book (reduced rate)", "quantity": 3, "unit": "C62", "unitPrice": 40.00, "vatRate": 6.0, "vatCategory": "S" }, { "description": "Support plan (per month)", "quantity": 12, "unit": "MON", "unitPrice": 99.00, "vatRate": 21.0, "vatCategory": "S" }, { "description": "Intra-EU goods (exempt)", "quantity": 1, "unit": "C62", "unitPrice": 500.00, "vatRate": 0.0, "vatCategory": "K", "vatExemptionReason": "Intra-Community supply, art. 138 Directive 2006/112/EC", "vatExemptionCode": "VATEX-EU-IC" } ] } } [/code] Line detail (units & item codes) lines Per-line unit of measure (`unit`, UN/ECE Rec 20 — HUR hour, MON month, KGM kg, C62 unit), item reference (`itemCode`) and VAT category. [code] { "type": "invoice", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0501", "issueDate": "2026-04-30", "currency": "EUR", "orderReference": "PO-2026-0042", "lines": [ { "description": "Managed hosting", "quantity": 1, "unit": "MON", "unitPrice": 1200.00, "vatRate": 21.0, "vatCategory": "S", "itemCode": "SKU-HOST-PRO" }, { "description": "Steel bar", "quantity": 250, "unit": "KGM", "unitPrice": 3.20, "vatRate": 21.0, "vatCategory": "S", "itemCode": "SKU-STEEL-16" } ] } } [/code] Prepayment invoice / acompte 386 Advance billed before delivery. See [Prepayment invoices](<#prepayment>). [code] { "type": "invoice", "documentSubtype": "PREPAYMENT_INVOICE", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "ACPT-2026-0042", "issueDate": "2026-04-15", "currency": "EUR", "orderReference": "PO-2026-0042", "note": "Acompte 30 percent - commande PO-2026-0042", "lines": [ { "description": "Advance - 30 percent of project fee", "quantity": 1, "unitPrice": 3000.00, "vatRate": 21.0 } ] } } [/code] Corrected invoice 384 Replaces a prior invoice with corrected content; references the original. [code] { "type": "invoice", "documentSubtype": "CORRECTED_INVOICE", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0042-R1", "issueDate": "2026-04-20", "currency": "EUR", "billingReference": "INV-2026-0042", "billingReferenceDate": "2026-04-15", "lines": [ { "description": "Consulting services (corrected quantity)", "quantity": 8, "unitPrice": 150.00, "vatRate": 21.0 } ] } } [/code] Credit note 381 Reduces or cancels a prior invoice. See [Credit & debit notes](<#credit-debit>). [code] { "type": "credit-note", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "CN-2026-0007", "issueDate": "2026-05-02", "currency": "EUR", "billingReference": "INV-2026-0042", "billingReferenceDate": "2026-04-15", "lines": [ { "description": "Refund - consulting services", "quantity": 2, "unitPrice": 150.00, "vatRate": 21.0 } ] } } [/code] Debit note 383 Increases a prior invoice with an extra charge. [code] { "type": "debit-note", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "DN-2026-0003", "issueDate": "2026-05-05", "currency": "EUR", "billingReference": "INV-2026-0042", "billingReferenceDate": "2026-04-15", "lines": [ { "description": "Late-delivery surcharge", "quantity": 1, "unitPrice": 90.00, "vatRate": 21.0 } ] } } [/code] Self-billing / autofacturation 389 You (the customer) issue for the supplier; roles flip. See [Self-billing](<#self-billing>). [code] { "type": "invoice", "selfBilled": true, "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "SB-2026-0100", "issueDate": "2026-04-15", "currency": "EUR", "lines": [ { "description": "Grain delivery - March", "quantity": 12, "unitPrice": 210.00, "vatRate": 6.0 } ] } } [/code] Reverse charge (self-account VAT) AE Cross-border supply where the buyer accounts for the VAT. See [Self-invoicing](<#self-invoice>). [code] { "type": "invoice", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "RC-2026-0055", "issueDate": "2026-04-15", "currency": "EUR", "note": "Reverse charge - VAT to be accounted for by the customer", "lines": [ { "description": "Cross-border consulting (reverse charge)", "quantity": 5, "unitPrice": 200.00, "vatRate": 0.0, "vatCategory": "AE", "vatExemptionReason": "Reverse charge, art. 196 Directive 2006/112/EC", "vatExemptionCode": "VATEX-EU-AE" } ] } } [/code] Multiple parties (factoring payee) parties A payee distinct from the seller. See [Multiple parties](). [code] { "type": "invoice", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0200", "issueDate": "2026-04-15", "currency": "EUR", "parties": [ { "role": "seller", "id": "0009:FR86797978996", "name": "ACME FRANCE", "initiator": true }, { "role": "buyer", "id": "0009:BE0123456789", "name": "MEGACORP BE" }, { "role": "payee", "vatNumber": "FR90123456789", "name": "ACME FACTORING SAS" } ], "lines": [ { "description": "Consulting services", "quantity": 10, "unitPrice": 150.00, "vatRate": 21.0 } ] } } [/code] Purchase request / requisition order The buyer's internal request to authorise a purchase, ahead of the order. See [Orders, quotes & requisitions](<#orders>). [code] { "type": "purchase-request", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "PR-2026-0042", "issueDate": "2026-04-08", "currency": "EUR", "lines": [ { "description": "Office chairs (requisition)", "quantity": 20, "unitPrice": 120.00, "vatRate": 21.0 } ] } } [/code] Purchase order order An order sent by the buyer to the seller. [code] { "type": "purchase-order", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "PO-2026-0042", "issueDate": "2026-04-10", "currency": "EUR", "lines": [ { "description": "Office chairs", "quantity": 20, "unitPrice": 120.00, "vatRate": 21.0 } ] } } [/code] Sales order order The seller's order acknowledgement back to the buyer. [code] { "type": "sales-order", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "SO-2026-0042", "issueDate": "2026-04-11", "currency": "EUR", "orderReference": "PO-2026-0042", "lines": [ { "description": "Office chairs", "quantity": 20, "unitPrice": 120.00, "vatRate": 21.0 } ] } } [/code] Quote quote A quotation ahead of any order. [code] { "type": "quote", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "Q-2026-0042", "issueDate": "2026-04-01", "currency": "EUR", "lines": [ { "description": "Annual support plan", "quantity": 1, "unitPrice": 5000.00, "vatRate": 21.0 } ] } } [/code] Event event An observability record — no recipient, so `to` is omitted. [code] { "type": "event", "from": "0009:FR86797978996", "document": { "number": "INV-2026-0042" } } [/code] Where's the expense payload? There isn't one — an [expense](<#expenses>) is _received_ , not sent. The invoice-backed case is just the supplier's `invoice` arriving inbound; the no-invoice case is declared via e-reporting. Neither is a `POST /v1/documents/send` you make. ## Two axes: document type & invoice subtype It helps to keep two concepts separate: * **Document type** (`type`) — _what kind of document_ this is: an invoice, a credit note, an order, a quote. It is a fixed enum and it drives Peppol routing (which document type the recipient must be able to receive). * **Invoice subtype** (`documentSubtype`) — _which kind of invoice_ , when `type: "invoice"`. It is rendered as the UBL `InvoiceTypeCode` (BT-3) using the UNCL1001 code list — `380` for a plain commercial invoice, `386`/`384`/`389` for prepayment / corrected / self-billed. A credit note carries its own UNCL1001 code (`381`) derived from `type: "credit-note"`; you do not set `documentSubtype` for it. The subtype axis exists only to distinguish sub-kinds _of an invoice_. ## Document types (`type`) The `type` enum on [`POST /v1/documents/send`](). The first six are Peppol-routed business documents and require a `to`; `event` is a pure observability record and has no recipient. `type`| What it is| UNCL1001 code (BT-3)| Notes ---|---|---|--- `invoice`| Commercial invoice — a demand for payment for goods/services (B2B, B2C, B2G).| `380` (default; overridable via [`documentSubtype`](<#invoice-subtypes>))| The workhorse. See [invoice subtypes](<#invoice-subtypes>) for prepayment / corrected / self-billed. `credit-note`| Reduces or cancels a previously issued invoice (a return, a rebate, an error).| `381`| Link the original with `document.billingReference` — **required** under the FR reform. See [below](<#credit-debit>). `debit-note`| Increases a previously issued invoice (an extra charge after the fact).| `383`| Also requires `document.billingReference` under the FR reform. `purchase-order`| An order sent by the buyer to the seller.| —| Ordering document, not a fiscal invoice. See [Purchase orders](). `purchase-request`| A purchase requisition — the buyer's internal request to authorise a purchase, ahead of the order.| —| Maps to the transaction-documents `PURCHASE_REQUEST`. See [Orders, quotes & requisitions](<#orders>). `sales-order`| The seller's order acknowledgement / confirmation back to the buyer.| —| Pairs with `purchase-order` in an order-to-invoice flow. `quote`| A quotation / proposal, ahead of any order.| —| No fiscal effect; the first step of the quote → order → invoice chain. `goods-receipt`| The buyer's record that the goods actually arrived — quantities received against what was ordered.| —| Closes the order loop: it is what a three-way match checks the invoice against, alongside the `purchase-order`. No fiscal effect. The _seller's_ side of the same delivery is not a document type — reference the delivery note on the invoice with `document.despatchAdviceReference` (BT-16) instead. `event`| An observability / audit record about a document — no transport, no recipient.| —| The only type where `to` is optional. Carries just `document.number` and metadata. A minimal invoice send: [code] curl -X POST https://api.flowie.ink/v1/documents/send \ -H "Authorization: Bearer $FLOWIE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "invoice", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0042", "issueDate": "2026-04-15", "currency": "EUR", "lines": [ { "description": "Consulting services", "quantity": 10, "unitPrice": 150.00, "vatRate": 21.0 } ] } }' [/code] ## Invoice subtypes (`documentSubtype`) When `type: "invoice"`, the optional `documentSubtype` field selects the UNCL1001 `InvoiceTypeCode` (BT-3) rendered on the UBL. It accepts the `CAPITAL_SNAKE_CASE` name or the raw numeric code (e.g. `"386"`). It is only valid for `type: "invoice"` — sending it on any other type is a `400`. The four below are the named, modelled sub-kinds; because the field is a UNCL1001 pass-through, any other valid BT-3 code you send is tagged and rendered as-is. Name| Code| Meaning| How to send ---|---|---|--- (default)| `380`| Commercial invoice — an ordinary sale.| Omit `documentSubtype`. `PREPAYMENT_INVOICE`| `386`| Prepayment / down-payment invoice (_facture d'acompte_) — billed before delivery; netted out by the final invoice. See [Prepayment invoices](<#prepayment>).| `"documentSubtype": "PREPAYMENT_INVOICE"` `CORRECTED_INVOICE`| `384`| Corrected invoice (_facture rectificative_) — replaces a prior invoice with corrected content. See [Corrected invoices](<#corrected>).| `"documentSubtype": "CORRECTED_INVOICE"` `SELF_BILLED_INVOICE`| `389`| Self-billed invoice (_autofacturation_) — the customer issues on the supplier's behalf. See [Self-billing](<#self-billing>).| Prefer the `selfBilled: true` flag — it also flips the party roles. Prefer the `selfBilled` flag for `389` Setting `documentSubtype: "SELF_BILLED_INVOICE"` tags the UBL but does _not_ swap Seller and Buyer. The top-level [`selfBilled: true`](<#self-billing>) flag does both — tags `389` _and_ flips the roles — so it is the right choice for real self-billing. ## Credit & debit notes A credit note (`type: "credit-note"`, UNCL1001 `381`) reduces or cancels a prior invoice; a debit note (`type: "debit-note"`, `383`) increases one. Both are first-class documents that flow through the same lifecycle as an invoice — a credit note is _not_ a lifecycle status on the original invoice. Under the French reform, both must reference the invoice they amend via `document.billingReference` (BT-25, the UBL `BillingReference/InvoiceDocumentReference/ID`) and, where known, `document.billingReferenceDate` (BT-26). Omitting the reference on a FR credit/debit note fails validation (`BR-FR-CO-04`/`BR-FR-CO-05`). [code] curl -X POST https://api.flowie.ink/v1/documents/send \ -H "Authorization: Bearer $FLOWIE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "credit-note", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "CN-2026-0007", "issueDate": "2026-05-02", "currency": "EUR", "billingReference": "INV-2026-0042", "billingReferenceDate": "2026-04-15", "lines": [ { "description": "Refund — consulting services", "quantity": 2, "unitPrice": 150.00, "vatRate": 21.0 } ] } }' [/code] ## Prepayment invoices (_facture d'acompte_) A **prepayment invoice** — _facture d'acompte_ , or down-payment / advance invoice — bills an amount **before** the goods are delivered or the service is completed. It is a real, VAT-bearing invoice in its own right (with its own number and, where the advance is taxable, VAT due on the advance) — not a proforma or a quote. Tag it with the UNCL1001 subtype `386` via `documentSubtype`: [code] curl -X POST https://api.flowie.ink/v1/documents/send \ -H "Authorization: Bearer $FLOWIE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "invoice", "documentSubtype": "PREPAYMENT_INVOICE", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "ACPT-2026-0042", "issueDate": "2026-04-15", "currency": "EUR", "orderReference": "PO-2026-0042", "note": "Acompte 30% — commande PO-2026-0042", "lines": [ { "description": "Advance — 30% of project fee", "quantity": 1, "unitPrice": 3000.00, "vatRate": 21.0 } ] } }' [/code] You can send the numeric code instead of the name (`"documentSubtype": "386"`) — both render the same UBL `InvoiceTypeCode` (BT-3). Like every subtype it is only valid for `type: "invoice"`. **Settling the advance.** When the work is done you issue the _final_ (balance) invoice as an ordinary `type: "invoice"` (subtype `380`) and **deduct the amount already invoiced on the acompte** , so the customer is billed only the remaining balance — carry the deduction as a negative line (or, with `format=ubl-xml`, a document-level allowance) and cite the acompte's number in `document.note` or `document.orderReference` for the audit trail. The acompte and the balance invoice together add up to the full order value. Country specifics In 🇮🇹 Italy the advance is its own _TipoDocumento_ — `TD02` (_acconto/anticipo su fattura_) or `TD03` (_su parcella_) — set through `document.note`; see [Italian document types](<../compliance/it/document-types.html>). Under the 🇫🇷 French reform the acompte follows the standard e-invoice flow carrying `InvoiceTypeCode` `386`. ## Corrected invoice (_facture rectificative_) A **corrected invoice** re-issues an invoice whose content was wrong — a mistyped amount, the wrong line, a bad VAT rate — as a fresh, self-standing invoice that **replaces** the original rather than adjusting it. Tag it with the UNCL1001 subtype `384` via `documentSubtype`, and point it at the invoice it supersedes with `document.billingReference` (BT-25) so the chain stays auditable: [code] curl -X POST https://api.flowie.ink/v1/documents/send \ -H "Authorization: Bearer $FLOWIE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "invoice", "documentSubtype": "CORRECTED_INVOICE", "from": "0009:FR86797978996", "to": "0009:BE0123456789", "document": { "number": "INV-2026-0042-R1", "issueDate": "2026-04-20", "currency": "EUR", "billingReference": "INV-2026-0042", "billingReferenceDate": "2026-04-15", "lines": [ { "description": "Consulting services (corrected quantity)", "quantity": 8, "unitPrice": 150.00, "vatRate": 21.0 } ] } }' [/code] Send the numeric code if you prefer (`"documentSubtype": "384"`); like every subtype it is only valid for `type: "invoice"`. **Corrected invoice vs. credit note.** A corrected invoice (`384`) _replaces_ the original with the right figures. An [avoir / credit note](<#credit-debit>) instead _cancels or reduces_ the original and leaves it standing — often followed by a brand-new invoice. Under the French reform the credit-note route is the usual way to correct an already-transmitted invoice; reach for `384` when a single rectifying invoice that references the original is the cleaner record. Either way, carry the link in `document.billingReference`. Correcting before vs. after transmission Nothing sent yet? Just fix and send the invoice normally — there is no correction to model. The `384` subtype (and the `billingReference` link) is for when the original has already reached the buyer and the tax authority and must be superseded on the record. ## Self-billing (_autofacturation_) **Self-billing** is the arrangement where the **customer issues the invoice on the supplier's behalf** — common in agriculture, marketplaces, and royalty settlements, and permitted where the two parties have agreed to it. It is still a two-party sale between a distinct seller and buyer; only the party who _issues_ the document changes. Set it with the top-level `selfBilled: true` flag. Flowie then: * treats the acting organization (`from`) as the **Buyer** / initiator; * treats `to` as the **Seller** (the supplier being billed); * tags the document with UNCL1001 subtype `389` (Self-Billed Invoice). It is a shorthand for `documentSubtype: "SELF_BILLED_INVOICE"` that _also_ flips the roles, and it is only valid for `type: "invoice"` — self-billed credit notes (UNCL1001 `261`) are not yet modelled downstream, so `selfBilled` on any other type is a `400`. [code] curl -X POST https://api.flowie.ink/v1/documents/send \ -H "Authorization: Bearer $FLOWIE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "invoice", "selfBilled": true, "from": "0009:FR86797978996", # you — the customer, issuing on the supplier'"'"'s behalf "to": "0009:BE0123456789", # the supplier — becomes the Seller "document": { "number": "SB-2026-0100", "issueDate": "2026-04-15", "currency": "EUR", "lines": [ { "description": "Grain delivery — March", "quantity": 12, "unitPrice": 210.00, "vatRate": 0.0 } ] } }' [/code] Self-billing with a third party When the self-billed document also involves a distinct `payer` or `payee` (e.g. a factoring arrangement), drop the `selfBilled` shorthand and describe every role explicitly with [`document.parties`](): one entry per role, with exactly one carrying `initiator: true` (the org your key acts as). ## Self-invoicing & reverse charge (_autofattura_) "Self-invoice" is also used for a different, VAT-driven case: under a **reverse charge** or on a cross-border purchase, the **buyer issues a document to account for the VAT itself** , because the supplier did not (or could not) charge it. Here the same party is effectively both seller and buyer of record — it is not the two-party self-billing above. How this is expressed depends on the jurisdiction: * **🇮🇹 Italy (SDI).** Self-invoices and integrations carry a dedicated _TipoDocumento_ — `TD16`–`TD19` for reverse charge and foreign purchases, `TD20`/`TD21`/`TD27`/`TD29` for the _autofatture_ where seller = buyer. Set the code via `document.note`; Flowie validates the seller/buyer and country rules before transmission. See the full table on [Italian document types (TD01–TD29)](<../compliance/it/document-types.html>). * **Cross-border / EN 16931.** On the structured invoice, a reverse-charge or exempt supply is carried per line with the right `vatCategory` (`AE` reverse charge, `K` intra-community, `G` export, `E` exempt, `O` out of scope) plus a stated exemption reason — see [Tax exemption & zero rate](). Flowie renders the matching BG-23 VAT breakdown so the zero-VAT category is declared rather than a bogus 0 % standard rate. Two things both called "self-invoice" **Self-billing** (`selfBilled: true`, UNCL1001 `389`) = the customer issues a normal invoice for a real supplier, roles flipped. **Reverse-charge self-invoicing** (Italian _autofattura_ , TD16–TD29) = the buyer issues a document to self-account for VAT. Pick by _why_ you are issuing, not just the word. ## Orders, quotes & requisitions Not every document is an invoice. Flowie also carries the **pre-invoice** documents of the procure-to-pay chain — the ones that lead up to the bill. They flow through the same [`POST /v1/documents/send`]() pipeline; only the `type` changes. * **Purchase request** (`type: "purchase-request"`) — a _purchase requisition_ : the buyer's internal request to authorise a purchase, the first step of the chain. Try the [Purchase request example](<#try-it>). * **Quote** (`type: "quote"`) — a quotation / proposal the seller sends. No fiscal effect. Try the [Quote example](<#try-it>). * **Purchase order** (`type: "purchase-order"`) — the buyer's order to the seller. Try the [Purchase order example](<#try-it>). * **Sales order** (`type: "sales-order"`) — the seller's acknowledgement back to the buyer, pairing with the purchase order. These are order-side documents, not fiscal invoices. Chain the whole thread — _requisition → quote → order → invoice_ — by carrying `document.orderReference` (and `document.buyerReference`) forward from one document to the next, so it stays linkable end to end. About `purchase-request` (the requisition) A **purchase requisition** (PR) is the internal approval a buyer raises before a [purchase order](<#orders>) goes to the supplier. Flowie carries it as the `purchase-request` type, rendered as the transaction-documents `PURCHASE_REQUEST` document. Like the other order-side types it takes a `from`/`to` and a `document` body; put the requisition number in `document.number` and any originating reference in `document.buyerReference`. ## Expenses (employee & card spend) There is **no`expense` document type** — an expense is not a thing you _send_ , it is spend you _account for_ , and it maps onto the model above in one of two ways depending on whether a supplier invoice exists: * **Expense backed by a supplier invoice** (a hotel, a SaaS subscription, a supplier that issues a proper invoice). This is just an ordinary `type: "invoice"` that you _receive_ — your company is the buyer, and it arrives inbound like any other invoice (see [Document · direction]()). Nothing expense-specific: it is captured, matched and booked as a received invoice. This is French reform _cas d'usage_ 5. * **Expense with no invoice** — a restaurant receipt, a toll ticket, a taxi, a lodged-card purchase. There is no structured invoice to exchange over Peppol/PA, so the amount is declared to the tax authority as **e-reporting** (transaction / payment _data_), not sent as an e-invoice. These are French _cas d'usage_ 6 (expenses without an invoice), 27 (toll tickets), 28 (restaurant receipts) and 7 (lodged corporate card). Expenses are received, not a send type Because expenses are the buyer-side view of a supplier's invoice (or a receipt reported as data), they never need a new `type` value. For the invoice-backed case, receive and reconcile the inbound invoice; for the no-invoice case, see the [e-reporting deep dive](<../compliance/fr/use-cases.html#ereporting>) and the full [cas d'usage referential](<../compliance/fr/use-cases.html#all>) (cases 5–7, 27, 28). ## Which one do I use? * Ordinary sale → `type: "invoice"` (subtype defaults to `380`). * Billing an advance before delivery ([acompte](<#prepayment>)) → `type: "invoice"` \+ `documentSubtype: "PREPAYMENT_INVOICE"`. * Replacing an invoice's content → `type: "invoice"` \+ `documentSubtype: "CORRECTED_INVOICE"`. * Reducing / cancelling an invoice → `type: "credit-note"` with `billingReference`. * Charging more after the fact → `type: "debit-note"` with `billingReference`. * You are the customer issuing for the supplier → `type: "invoice"` \+ `selfBilled: true`. * Self-accounting for VAT under reverse charge (IT) → `type: "invoice"` \+ the right `TD` code in `document.note`. * Requisitioning a purchase (internal request) → `type: "purchase-request"`. * Ordering / quoting → `type: "purchase-order"`, `"sales-order"`, or `"quote"`. * Recording an event, no recipient → `type: "event"`. * Booking an [expense](<#expenses>) → not a send type: receive the supplier's `invoice`, or e-report it when there's no invoice. ## References * [Send a document]() — the endpoint, every field including `type`, `documentSubtype` and `selfBilled`. * [Multiple parties]() — explicit role-tagged parties for self-billing with a third party. * [Tax exemption & zero rate]() — VAT categories and exemption reasons for reverse-charge and exempt supplies. * [Data model · Document]() — the three orthogonal status fields on every document. * [Italy · Document types (TD01–TD29)](<../compliance/it/document-types.html>) — the full _TipoDocumento_ referential, including the _autofatture_.