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, the four invoice subtypes (including self-billed invoices), and how the two flavours of self-invoice — self-billing and reverse-charge self-invoicing — 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 — 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.

{
  "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 }
    ]
  }
}

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.

{
  "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" }
    ]
  }
}

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.

{
  "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" }
    ]
  }
}

Prepayment invoice / acompte 386

Advance billed before delivery. See Prepayment invoices.

{
  "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 }
    ]
  }
}

Corrected invoice 384

Replaces a prior invoice with corrected content; references the original.

{
  "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 }
    ]
  }
}

Credit note 381

Reduces or cancels a prior invoice. See Credit & debit notes.

{
  "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 }
    ]
  }
}

Debit note 383

Increases a prior invoice with an extra charge.

{
  "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 }
    ]
  }
}

Self-billing / autofacturation 389

You (the customer) issue for the supplier; roles flip. See Self-billing.

{
  "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 }
    ]
  }
}

Reverse charge (self-account VAT) AE

Cross-border supply where the buyer accounts for the VAT. See Self-invoicing.

{
  "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"
      }
    ]
  }
}

Multiple parties (factoring payee) parties

A payee distinct from the seller. See Multiple parties.

{
  "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 }
    ]
  }
}

Purchase request / requisition order

The buyer's internal request to authorise a purchase, ahead of the order. See Orders, quotes & requisitions.

{
  "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 }
    ]
  }
}

Purchase order order

An order sent by the buyer to the seller.

{
  "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 }
    ]
  }
}

Sales order order

The seller's order acknowledgement back to the buyer.

{
  "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 }
    ]
  }
}

Quote quote

A quotation ahead of any order.

{
  "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 }
    ]
  }
}

Event event

An observability record — no recipient, so to is omitted.

{
  "type": "event",
  "from": "0009:FR86797978996",
  "document": {
    "number": "INV-2026-0042"
  }
}

Where's the expense payload?

There isn't one — an expense 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`)	The workhorse. See 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.
`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.
`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.
`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:

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 }
      ]
    }
  }'

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.	`"documentSubtype": "PREPAYMENT_INVOICE"`
`CORRECTED_INVOICE`	`384`	Corrected invoice (facture rectificative) — replaces a prior invoice with corrected content. See Corrected invoices.	`"documentSubtype": "CORRECTED_INVOICE"`
`SELF_BILLED_INVOICE`	`389`	Self-billed invoice (autofacturation) — the customer issues on the supplier's behalf. See 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 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).

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 }
      ]
    }
  }'

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:

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 }
      ]
    }
  }'

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. 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:

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 }
      ]
    }
  }'

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 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.

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 }
      ]
    }
  }'

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).
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.
Quote (type: "quote") — a quotation / proposal the seller sends. No fiscal effect. Try the Quote example.
Purchase order (type: "purchase-order") — the buyer's order to the seller. Try the Purchase order example.
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 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 and the full cas d'usage referential (cases 5–7, 27, 28).

Which one do I use?

Ordinary sale → type: "invoice" (subtype defaults to 380).
Billing an advance before delivery (acompte) → 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 → 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) — the full TipoDocumento referential, including the autofatture.