Create Document
Issue a document: a sale/purchase invoice, a credit note or a proforma.
Only what identifies the document and what it bills is provided. Everything else is
derived and refused if sent: the number comes from the journal’s numbering sequence, the
payment communication is a structured one built from the document itself, and all the
amounts are computed from the lines (subtotal = quantity x unit price, then the VAT of
each rate, then the totals). payment_status follows from paid_amount, and the document
starts waiting on the accounting side.
The third party is given by relation_id alone: the same identifier space covers business
relations and contacts, so which of the two it is never has to be declared — the response
says it in relation_type.
payment_terms drives the due date, which is always derived from it and from the issue
date — due_date is accepted but ignored. The terms themselves default to the ones set on
the third party, and to 30-df when it has none — which is always the case for a contact.
The journal must match the document type (a sale invoice goes in a sales_invoice
journal, a purchase credit note in a purchases_credit one); omit journal_id to use the
company’s default journal for that category. purchase_invoice and purchase_credit_note
are self-billing documents and require self-billing to be enabled on the company.
The PDF and, when the type allows it, the Peppol XML are rendered asynchronously: they are
false on the freshly created document and become available shortly after — poll
GET /documents/{id} to follow it. In sandbox mode the body is validated exactly as in
live mode but nothing is stored, so the returned id is not resolvable.
By default nothing leaves: the document is written and rendered, and that is all. Add
?send_peppol=true to have it put on the network as soon as its files exist — which requires
the u permission on top of the c, and a type Peppol carries (not a proforma). One flag
per channel, because the channels are independent: mail will join as send_mail, and a
document may need one, the other, or both. The send stays asynchronous: the 201 says the
document exists, not that it was delivered.
When the send was asked for but could not be started, the answer is 422 send_failed
instead of the 201: the error names the document, which was created and numbered.
Do not create it again — retry the send with POST /documents/{id}/send.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Query Parameters
Put the document on the Peppol network as soon as it is written. Requires the u permission in addition to c, and a type Peppol carries. A query parameter, not a body field: it drives what the call does, it is not part of the document. One flag per channel — mail will join as send_mail, the two being independent. Omit it and nothing leaves.
Body
A document to issue: an invoice, a credit note or a proforma.
Only what identifies the document and what it bills is provided here. Its number, its payment communication and every amount are computed from the lines and the journal.
Kind of document to issue. One of ['sale_invoice', 'sale_credit_note', 'purchase_invoice', 'purchase_credit_note', 'proforma_invoice'].
Opaque identifier of the third party the document is issued to. It says by itself whether it is a company or a contact — nothing else has to be declared.
The lines to invoice. At least one is required, 500 at most.
1 - 500 elementsIgnored: the nature of the third party is read from relation_id, and the relation_type of the response is what it really is. Accepted rather than refused so a document that was read can be posted back unchanged.
Ignored: files are attached with POST /documents/{id}/attachments, never through this body. Accepted so a document that was read can be sent back unchanged.
Opaque identifier of the journal to book the document in. Defaults to the company's default journal for the category the type requires.
Opaque identifier of one of the third party's saved delivery addresses (GET /delivery-locations?relation_id=…), to record where the goods go. It must belong to the same third party as the document.
Date the document is issued. Defaults to today, and cannot be in the future — a document dated ahead falls outside the window its number is drawn from, and that number would be handed out again to the next document.
Ignored: always derived from payment_terms, counted from the issue date — the terms are the only thing a caller drives. Accepted rather than refused so a document that was read can be sent back unchanged.
Payment terms, as <days>-<basis> where days is 0 or more and the basis is df (from the document's date), fm (from the first day of the following month) or mf (end of the month the delay lands in) — for example 30-df, 0-df for immediate payment. Defaults to the terms set on the third party, and to 30-df when it has none (a contact never has any).
^\d{1,4}-(df|fm|mf)$Date the VAT becomes chargeable, when it differs from the issue date.
Date the goods/services were actually delivered — a fact, not a plan: today or earlier, never a future date.
First day of the billed period.
Last day of the billed period.
Purchase/sales order number referenced by the document.
255Reference of the despatch advice (delivery note).
50Reference given by the buyer (e.g. a cost centre).
50Legal mention printed at the bottom of the document. On a sale invoice it defaults to the one configured on the company, as in the interface. Independently of it, every exempt VAT group (exempted, intra_community, export, reverse_charge, not_subject) carries its own exemption mention on the PDF and in the Peppol XML — the company's configured text for that code, else a standard wording.
10000ISO 4217 currency code of every amount, among those Fidly supports (EUR, USD, GBP…). Defaults to EUR.
20Amount already paid, tax included. Drives payment_status; defaults to 0 (unpaid).
0 <= x <= 999999999Discounts and surcharges on the document as a whole, applied after the lines and their own. A rate is a percentage of the document's line total; a fixed amount is taken off in full. Each one is spread over the VAT rates of the document in proportion to what they weigh, because the tax it saves belongs to each of them. That spread needs every rate to total a positive amount: if the lines of one rate add up to a negative amount, put the discount on the lines instead.
50Response
Successful Response
A document of the company: an invoice/credit note it issued or a document it
received (purchase invoice, credit note, other). The source table is hidden — the
client sees a single unified document identified by an opaque id.
Monetary amounts are decimal numbers in the document's currency. They may be null
when the document could not be parsed automatically, or for other_document types
that have no financial breakdown.
Both sources are normalised to this shape by the repository adapters; the validators below map the internal codes to their public values.
Opaque unique identifier of the document.
Document type. One of: sale_invoice, sale_credit_note, purchase_invoice, purchase_credit_note, other_document, unknown.
Channel the document came in through. One of: fidly (generated in Fidly), manual, peppol, mail, odoo, billit, api (or unknown).
The document's own number (e.g. invoice number).
Purchase/sales order number referenced by the document.
Reference of the despatch advice (delivery note) related to the document.
Reference given by the buyer, to be quoted back on the document (e.g. a cost centre).
Date the document was issued (ISO YYYY-MM-DD).
Payment due date (ISO YYYY-MM-DD).
Date the VAT becomes chargeable, when it differs from the issue date (ISO YYYY-MM-DD).
Date the goods/services were actually delivered (ISO YYYY-MM-DD).
First day of the period the document bills (ISO YYYY-MM-DD).
Last day of the period the document bills (ISO YYYY-MM-DD).
Communication to quote when paying the document. null when the document carries none.
true when payment_remittance is a structured communication (a bank-checked reference such as a Belgian OGM/VCS) rather than free text. Always true for documents issued by Fidly.
Timestamp the document was created in Fidly (ISO 8601). May be null on rare legacy rows where it was never set.
ISO 4217 currency code of all amounts (e.g. EUR).
Total amount excluding tax.
Total tax (VAT) amount.
Total amount payable, tax included.
Amount already paid.
Amount still to be paid (total_amount minus paid_amount).
Payment state. One of: unpaid, partial, paid (or unknown).
Accounting workflow state. One of: waiting, accepted, transfered, exported, export_error, imported, validated, hidden, exporting, posting, posting_error, deleted (or unknown).
true if a PDF is stored for this document (retrievable via the file endpoint).
true if a structured XML version (e.g. Peppol/UBL) is stored for this document.
Nature of relation_id: company (a registered business relation) or contact (an individual contact). null when there is no linked third party.
Opaque identifier of the third party the document is linked to (resolvable via GET /relations/{id}). Its nature is given by relation_type. null when the document has no linked third party.
Opaque identifier of the journal the document is booked in (resolvable via GET /journals/{id}). null when the document has no linked journal.
Opaque identifier of the saved delivery address the document is delivered to (resolvable via GET /delivery-locations/{id}). null when none is set.
Payment terms the due_date follows from, as <days>-<basis> (e.g. 30-df). Always null on a received document: only documents Fidly issues carry them.
Legal mention printed at the bottom of the document (e.g. a VAT exemption wording). Always null on received documents.
Peppol send state of an issued document. One of: not_sent, sending, sent (delivered to the network), accepted (acknowledged by the recipient), rejected (refused by the recipient), failed (or unknown). rejected and failed can be sent again. Always null on a received document.
E-mail send state of an issued document. One of: not_sent, sent, failed (or unknown). Always null on a received document.
Files attached to the document, in the order they were added. Attach one with POST /documents/{id}/attachments; the API offers no way to remove one. A received document never carries any.
Discounts/surcharges applied to the document as a whole, after the lines and their own. tax_exclusive_amount is already net of them.
Detailed lines of the document (invoiced items/services). Empty when none are stored.