Document schemas

Invopop stores every business document as a GOBL envelope. The envelope wraps the document payload with headers and digital signatures, and the payload’s $schema property declares which document type it is. A document’s schema determines which properties are valid, which workflow templates can process it, and which apps and tax regimes will accept it.

Supported schemas

Schema	Console section	Purpose
`bill/invoice`	Invoices	A payment claim for goods or services supplied under agreed conditions. The most widely used schema and the basis of most workflows.
`bill/order`	Orders	The opening step of an order-to-invoice process, where a buyer requests goods or services from a seller.
`bill/delivery`	Deliveries	The movement of goods, or occasionally services, between parties.
`bill/payment`	Payments	Links one or more invoices to a payment transaction.
`bill/status`	Statuses	A lifecycle event reported against a document, such as an acknowledgement, approval or refusal.
`org/party`	Parties	A legal entity or individual involved in a transaction, stored independently so it can be registered with a tax authority or network.
`org/item`	Items	A product or service offered for sale, stored independently to keep a consistent catalogue across documents.

Every document is wrapped in a signed envelope whose doc property carries the business document. The envelope and its header hold metadata about the document rather than business data, and are covered in Document contents.

Shared properties

The four billing schemas — invoice, order, delivery and payment — share a common set of properties.

Property	Notes
`$regime`	The tax regime the document belongs to, as an ISO country code. Determines default currency, tax categories and which correction types are available.
`$addons`	Regime or format extensions applied to the document, such as `es-verifactu-v1` or `pt-saft-v1`. Addons add their own normalisation, validation and extension keys.
`$tags`	Modifiers that change how the document is interpreted. See invoice tags.
`type`	The subtype within the schema. Each schema has its own set of values, listed on its own page.
`series`, `code`	The document’s identifier. `code` is required before a document can be signed, and is usually generated from a series.
`issue_date`, `issue_time`	When the document was issued. Defaults to today, and to the current time where the regime requires it.
`supplier`, `customer`	The parties to the transaction, as party objects. `customer` may be omitted on simplified invoices.
`preceding`	References to documents this one replaces or extends. See document references.
`lines`	The items, charges or referenced documents that make up the document body.
`meta`	Semi-structured data that has no home in the document body.

FAQ

Can I change a document's schema or type after it has been signed?

No. Signing fixes the document’s digest, and both the schema and the type form part of the signed payload. Issue a correction against the original instead, or replicate it into a new document if it was never issued.

Can one workflow process more than one schema?

Yes. A workflow can branch on the schema of the incoming entry, which is how regimes with overlapping flows are handled — France’s invoicing workflows accept both invoices and status documents. See workflows and document schemas.


Console	Document references Document contents Document states Create documents Series
API Reference	Create an entry (POST) Create an entry (PUT) Fetch all entries
GOBL	Envelope schema Invoicing use cases

​Supported schemas

​Shared properties

​FAQ

​Related resources

Supported schemas

Shared properties

FAQ

Related resources