data property containing the GOBL JSON of either a pre-built [Envelope](https://docs.gobl.org/draft-0/envelope) or a partial document like an [Invoice](https://docs.gobl.org/draft-0/bill/invoice) or [Party](https://docs.gobl.org/draft-0/org/party).
Use the `key` property to ensure idempotency. If the same key is used in the same workspace in another silo entry, the request will be rejected with `409 Conflict`. Note that idempotency using this method is intended for repeat requests whereby the system has had the opportunity to persist the first, we recommend using the [put](/api-ref/silo/entries/create-an-entry-put) method in concurrent scenarios.
```json Invoice Payload Example theme={"system"}
{
"key": "invoice-DEMO-001",
"data": {
"$schema": "https://gobl.org/draft-0/bill/invoice",
"series": "DEMO",
"code": "001",
"currency": "USD",
"supplier": {
"name": "Provide One Inc.",
"tax_id": {
"country": "US"
},
"addresses": [
{
"num": "16",
"street": "Jessie Street",
"locality": "San Francisco",
"region": "CA",
"code": "94105",
"country": "US"
}
],
"emails": [
{
"addr": "billing@provideone.com"
}
]
},
"customer": {
"name": "Sample Consumer",
"emails": [
{
"addr": "email@sample.com"
}
]
},
"lines": [
{
"quantity": "20",
"item": {
"name": "Development services",
"price": "90.00",
"unit": "h"
},
"discounts": [
{
"percent": "10%",
"reason": "Special discount"
}
],
"taxes": [
{
"cat": "ST",
"percent": "8.5%"
}
]
}
]
}
}
```
Any data uploaded to the Invopop Silo will first be normalized, calculated, and then validated to check for any errors.
Invopop will attempt to automatically determine the folder in which to store the document based on the schema, but you can override this by including the folder field in the request.
If there are any validation issues with the uploaded data, the service will respond with an error message including a `key` and `message`. Additionally, the `fields` property may include a nested structure to help identify the specific property with a validation fault.
## Creating Entries from Previous Documents
You can create new entries based on a previous entry by using the previous\_id field. This allows you to provide patch data instead of a full new document by setting the patch type in the content\_type field to one of the following:
* application/json-patch+json - for JSON Patch (RFC 6902)
* application/merge-patch+json - for JSON Merge Patch (RFC 7396)
Additionally, the previous\_id field can be used to create corrective documents by including corrective option data in the correct field. For more details, refer to the GOBL documentation on correction options.
# Create an entry with ID
Source: https://docs.invopop.com/api-ref/silo/entries/create-an-entry-put
PUT /silo/v1/entries/{id}
Create a new silo entry with the given UUID.
## New Documents
The fastest way to upload data to Invopop is by creating an entry with the data property containing the GOBL JSON of either a pre-built [Envelope](https://docs.gobl.org/draft-0/envelope) or a partial document like an [Invoice](https://docs.gobl.org/draft-0/bill/invoice) or [Party](https://docs.gobl.org/draft-0/org/party).
The `key` property can be used to ensure idempotency, preventing the creation of duplicate entries with the same key within the workspace.
A `409 Conflict` response will be provided if either the entry ID or key have been used in an existing document.
```json Invoice Body Example theme={"system"}
{
"data": {
"$schema": "https://gobl.org/draft-0/bill/invoice",
"series": "DEMO",
"code": "001",
"currency": "USD",
"supplier": {
"name": "Provide One Inc.",
"tax_id": {
"country": "US"
},
"addresses": [
{
"num": "16",
"street": "Jessie Street",
"locality": "San Francisco",
"region": "CA",
"code": "94105",
"country": "US"
}
],
"emails": [
{
"addr": "billing@provideone.com"
}
]
},
"customer": {
"name": "Sample Consumer",
"emails": [
{
"addr": "email@sample.com"
}
]
},
"lines": [
{
"quantity": "20",
"item": {
"name": "Development services",
"price": "90.00",
"unit": "h"
},
"discounts": [
{
"percent": "10%",
"reason": "Special discount"
}
],
"taxes": [
{
"cat": "ST",
"percent": "8.5%"
}
]
}
]
}
}
```
Any data uploaded to the Invopop Silo will first be normalized, calculated, and then validated to check for any errors.
Invopop will attempt to automatically determine the folder in which to store the document based on the schema, but you can override this by including the folder field in the request.
If there are any validation issues with the uploaded data, the service will respond with an error message including a `key` and `message`. Additionally, the `fields` property may include a nested structure to help identify the specific property with a validation fault.
previous\_id field. This allows you to provide patch data instead of a full new document by setting the patch type in the content\_type field to one of the following:
* application/json-patch+json - for JSON Patch (RFC 6902)
* application/merge-patch+json - for JSON Merge Patch (RFC 7396)
Additionally, the previous\_id field can be used to create corrective documents by including corrective option data in the correct field. For more details, refer to the GOBL documentation on correction options.
# Fetch all entries
Source: https://docs.invopop.com/api-ref/silo/entries/fetch-all-entries
GET /silo/v1/entries
Fetch all the silo entries in the current workspace.
# Fetch an entry
Source: https://docs.invopop.com/api-ref/silo/entries/fetch-an-entry
GET /silo/v1/entries/{id}
Fetch an existing silo entry given its UUID.
# Fetch an entry by key
Source: https://docs.invopop.com/api-ref/silo/entries/fetch-an-entry-by-key
GET /silo/v1/entries/key/{key}
Fetch an existing silo entry by its key.
# Fetch an entry version
Source: https://docs.invopop.com/api-ref/silo/entries/fetch-entry-version
GET /silo/v1/entries/{id}/versions/{version}
Retrieve the GOBL envelope data stored for a specific version of a Silo entry.
Use the `version` value returned in an entry's `version` or `versions` fields to retrieve that exact historical envelope. The response contains only the requested version identifier and its GOBL envelope data; other entry metadata remains available from the standard [fetch entry](/api-ref/silo/entries/fetch-an-entry) endpoint.
# Fetch a file
Source: https://docs.invopop.com/api-ref/silo/entries/files-fetch
GET /silo/v1/entries/{entry_id}/files/{id}
Download silo entry file's data. Content type and disposition will be set according to the source.
# Create a file without UUID
Source: https://docs.invopop.com/api-ref/silo/entries/files-post
POST /silo/v1/entries/{entry_id}/files
Add a new file to a silo entry without an explicit UUID. The file data can be provided inline as base64 encoded data, or omitted to create a placeholder. When data is not provided, you must provide sha256, size, and mime fields, and the response will include a `url` field that can be used to stream/upload the file contents directly via a PUT request to that URL. For non-enrolled users, only the `format` and `attachment` categories are allowed.
# Create a file with ID
Source: https://docs.invopop.com/api-ref/silo/entries/files-put
PUT /silo/v1/entries/{entry_id}/files/{id}
Add a new file to a silo entry with a specific UUID. The file data can be provided inline as base64 encoded data, or omitted to create a placeholder. When data is not provided, you must provide sha256, size, and mime fields, and the response will include a `url` field that can be used to stream/upload the file contents directly via a PUT request to that URL. For non-enrolled users, only the `format` and `attachment` categories are allowed.
# Find related entries
Source: https://docs.invopop.com/api-ref/silo/entries/find-related
GET /silo/v1/entries/{id}/related
Find silo entries whose document mentions the given entry's UUID.
# Search entries
Source: https://docs.invopop.com/api-ref/silo/entries/search-entries
GET /silo/v1/search
Perform a free-text search on all documents in the current workspace.
# Update an entry
Source: https://docs.invopop.com/api-ref/silo/entries/update-an-entry
PATCH /silo/v1/entries/{id}
Update an existing silo entry given its UUID.
# Build GOBL document
Source: https://docs.invopop.com/api-ref/silo/gobl/build
POST /silo/v1/gobl/build
Build GOBL Envelopes or Objects for validation purposes
# Correct GOBL envelope
Source: https://docs.invopop.com/api-ref/silo/gobl/correct
POST /silo/v1/gobl/correct
Correct or determine the correction options for a GOBL Envelope (not Object!)
Use this endpoint to help determine the options for correcting [GOBL](https://docs.gobl.org) documents and then perform the correction itself.
This is useful when you need to issue credit notes or corrective versions of a previously issued invoice and need clarity on the local options.
All requests to the endpoint require a **[GOBL Envelope](https://docs.gobl.org/draft-0/envelope)**, and cannot be used with a [GOBL Invoice](https://docs.gobl.org/draft-0/bill/invoice) or other GOBL object. This is because some tax regimes require specific details from the previous document's headers, like a special identification code.
Use the `show_options` flag to return a JSON Schema of the options that can be used with the provided document.
Once the options are clear, send in a new request with the `options` data to get an example corrected [GOBL Envelope](https://docs.gobl.org/draft-0/envelope). The same options data can be used with the [silo create entry endpoint](/api-ref/silo/entries/create-an-entry-post) and the `correct` property.
# Sign GOBL document
Source: https://docs.invopop.com/api-ref/silo/gobl/sign
POST /silo/v1/gobl/sign
Sign GOBL Envelopes or Objects
# Delete a file
Source: https://docs.invopop.com/api-ref/silo/spool/delete
DELETE /silo/v1/spool/{key}
Delete a previously uploaded entry from the spool.
# Download a file
Source: https://docs.invopop.com/api-ref/silo/spool/download
GET /silo/v1/spool/{key}
Download a previously uploaded entry from the spool.
# Upload a file
Source: https://docs.invopop.com/api-ref/silo/spool/upload
POST /silo/v1/spool
Upload temporary file data to the silo spool. Requires 'enrolled' scope.
The Silo Spool service can be used by **Applications** as a temporary file store. This can be useful for example when processing documents that need additional processing before being added to a Silo Entry as an attachment.
Additionally, the Silo Spool will be used in the Transform Jobs API when uploading files as data URIs.
# Create a job without a UUID
Source: https://docs.invopop.com/api-ref/transform/jobs/create-a-job-post
POST /transform/v1/jobs
Create a new job without an explicit ID.
Use this endpoint to execute a workflow, allowing the backend to assign the UUID.
This request will not be idempotent unless a `key` is provided. Keys are checked for uniqueness within the current workspace and are valid for up to 2 years. Note that the [put](/api-ref/transform/jobs/create-a-job-put) request is recommended for high concurrency scenarios.
To execute a job, provide one of the following fields:
* `silo_entry_id` - preferred, the UUID of the silo entry to process with the workflow.
* `data` - raw GOBL data of the job, which will be persisted to the silo before processing.
* `args` - a data object containing application-specific data used in the workflow's initial actions to prepare and upload a silo entry.
The `wait` query parameter can cause the server to block the incoming HTTP request and wait for up to the specified number of seconds. Typically, a workflow executes in under a second, but some actions may take longer. We recommend using the `wait` query parameter only in sandbox or testing environments, as workflows can sometimes exceed expected duration due to network failures or other temporary issues.
Arguments (`args`) are composed of string key-value pairs tailored to specific applications. Binary data can be included using Data URIs (`data:`), which must specify the content type and include a `name` parameter. For example: `data:text/plain;name=example.txt;base64,ZGF0YQ==`. Any data provided via this method will be automatically uploaded to the Silo Spool service and will remain accessible only through tokens issued for the corresponding workspace.
# Create a job with a UUID
Source: https://docs.invopop.com/api-ref/transform/jobs/create-a-job-put
PUT /transform/v1/jobs/{id}
Create a new job with the given ID.
Use this endpoint to execute a workflow with a specific time-based UUID, v7 or v1.
If the `key` property is provided, it will be checked for uniqueness within the current workspace and is valid for up to 2 years.
To execute a job, provide one of the following fields:
* `silo_entry_id` - preferred, the UUID of the silo entry to process with the workflow.
* `data` - raw GOBL data of the job, which will be persisted to the silo before processing.
* `args` - a data object containing application-specific data used in the workflow's initial actions to prepare and upload a silo entry.
The `wait` query parameter can cause the server to block the incoming HTTP request and wait for up to the specified number of seconds. Typically, a workflow executes in under a second, but some actions may take longer. We recommend using the `wait` query parameter only in sandbox or testing environments, as workflows can sometimes exceed expected durations due to network failures or other temporary issues.
Arguments (`args`) are composed of string key-value pairs tailored to specific applications. Binary data can be included using Data URIs (`data:`), which must specify the content type and include a `name` parameter. For example: `data:text/plain;name=example.txt;base64,ZGF0YQ==`. Any data provided via this method will be automatically uploaded to the Silo Spool service and will remain accessible only through tokens issued for the corresponding workspace.
# Fetch a job
Source: https://docs.invopop.com/api-ref/transform/jobs/fetch-a-job
GET /transform/v1/jobs/{id}
Fetch an existing job by ID.
# Fetch a job by key
Source: https://docs.invopop.com/api-ref/transform/jobs/fetch-a-job-by-key
GET /transform/v1/jobs/key/{key}
Fetch an existing job by a recent key.
# Fetch all jobs
Source: https://docs.invopop.com/api-ref/transform/jobs/fetch-all-jobs
GET /transform/v1/jobs
Fetch all jobs in the current workspace.
⬜ model 65 | See Customer | | `payment` | ✅ if not fully paid | See Payment | | `ordering` | ⬜ | | | `delivery` | ⬜ | | ### Tax Extensions | Extension | Required | Values | | --------------------------------- | -------- | ------------------------------------------------------------------- | | `tax.ext.br-nfe-model` | ✅ | `"55"` (NF-e, B2B) or `"65"` (NFC-e, B2C) | | `tax.ext.br-nfe-presence` | ✅ | See table below. Restricted by model. | | `tax.ext.br-nfe-regime` | ⬜ | `"1"`=Simples Nacional, `"2"`=Simples Nacional Excess, `"3"`=Normal | | `tax.ext.br-nfe-fiscal-incentive` | ⬜ | `"1"`=Has incentive, `"2"`=No incentive | **`br-nfe-presence` allowed values:** | Code | Description | NF-e (55) | NFC-e (65) | | ---- | ------------- | --------- | ---------- | | `0` | N/A | ✅ | ❌ | | `1` | In-person | ✅ | ✅ | | `2` | Internet | ✅ | ❌ | | `3` | Tele-service | ✅ | ❌ | | `4` | Home delivery | ❌ | ✅ | | `5` | Off-site | ✅ | ❌ | | `9` | Others | ✅ | ❌ | ```json theme={"system"} "tax": { "ext": { "br-nfe-model": "55", "br-nfe-presence": "1" } } ``` ### Notes At least one note with `key: "reason"` is **required**. It maps to the NF-e `natOp` field (nature of the operation). ### Supplier | Field | Required | Notes | | -------------------------------------- | -------- | --------------------------------------------------------------- | | `name` | ✅ | | | `tax_id.country` | ✅ | `"BR"` | | `tax_id.code` | ✅ | CNPJ (14 digits) or CPF (11 digits), Mod11 validated | | `identities[].key: "br-nfe-state-reg"` | ✅ | State Registration (Inscrição Estadual) | | `addresses` | ✅ | At least one | | `addresses[].country` | ✅ 🔧 | ISO country code. Auto-filled from `tax_id.country` if missing. | | `ext.br-ibge-municipality` | ✅ | 7-digit IBGE municipality code | ### Customer (Model 55 — required, Model 65 — optional) Brazilian customers must provide a Brazilian `tax_id`. Foreign customers can issue an NF-e by providing a country-qualified `identity` (e.g. a passport number) instead of a `tax_id`. | Field | Required | Notes | | ------------------------------------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | `tax_id.country` | ✅ for BR customers | `"BR"` | | `tax_id.code` | ✅ when `tax_id` is present | CNPJ or CPF | | `identities[]` with non-BR `country` | ✅ for foreign customers without a `tax_id` | E.g. `{ "key": "passport", "country": "US", "code": "US-FOREIGN-123" }` | | `addresses` | ✅ | | | `addresses[].country` | ✅ 🔧 | ISO country code. Auto-filled from the `tax_id` country or the first identity that declares a country. | | `addresses[].state` | ✅ for BR customers | Must be a valid Brazilian state acronym (e.g. `SP`). Not required for foreign customers. | | `ext.br-ibge-municipality` | ✅ for BR customers | 7-digit IBGE code. Not required for foreign customers. | ### Line items Required tax categories per line: `ICMS`, `PIS`, `COFINS`. `IPI` is optional. | Extension | Required | Notes | | ---------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `line.ext.br-nfe-cfop` | ✅ model 55
⬜ model 65 | CFOP (Código Fiscal de Operações e Prestações) code identifying the fiscal nature of the operation, e.g. `"5102"` for in-state resale. Required on every line of an NF-e (model 55). | Optional item identities: `item.identities[].key: "ncm" | "gtin" | "gtin+taxable"`. ### Payment Required when the invoice is not fully paid. Must include `payment.instructions.key`. Payment-means mapping is auto-set unless `key: "other"`.
e-Rechnung | |
OIOUBL
Finvoice
Finvoice
Factur-X
UN/CEFACT CII | Peppol BIS 3.0
Factur-X
UN/CEFACT CII | |
ZUGFeRD | XRechnung
Peppol BIS 3.0 | |
Peppol BIS 3.0 | |
Peppol BIS 3.0 | |
SI-UBL 2.0
Peppol BIS 3.0 | EHF Billing 3.0
Peppol BIS 3.0 | |
Peppol BIS 3.0 | |
[UN/CEFACT CII](/apps/uncefact-cii) |
This is a six-character, alphanumeric code that uniquely identifies a specific government agency and ensures the e-invoice is routed correctly. A single public entity can have multiple unique codes, each assigned to a different office within the organisation. It’s also known as a “unique office code” or “IPA code” (referring to the Index of Public Administrations \[IPA]). The unique code is mandatory. * **CIG code**
This is a 10-digit, alphanumeric code used to identify an offer. It must be indicated on the invoice, unless an exemption from the traceability requirement applies, as provided for by Law No. 136 of 13 August 2010. * **CUP code**
This is a 15-character, alphanumeric code that identifies a public investment project. It should only be entered if specifically requested by the company.
[Hacienda Foral de Álava](https://web.araba.eus/es/hacienda/ticketbai)
[Hacienda Foral de Bizkaia](https://www.batuz.eus/es/inicio) | | **Invopop support** | [Spain App](/apps/spain) (TicketBAI) |
| | |
| ------------ | ----- |
| Prefix | `ES-` |
| Padding | `5` |
| Start number | `1` |
| Code | `INV` |
```
INV-ES-00001
INV-ES-00002
INV-ES-00003
```
⬜ model 65 | See Customer | | `payment` | ✅ if not fully paid | See Payment | | `ordering` | ⬜ | | | `delivery` | ⬜ | | ### Tax Extensions | Extension | Required | Values | | --------------------------------- | -------- | ------------------------------------------------------------------- | | `tax.ext.br-nfe-model` | ✅ | `"55"` (NF-e, B2B) or `"65"` (NFC-e, B2C) | | `tax.ext.br-nfe-presence` | ✅ | See table below. Restricted by model. | | `tax.ext.br-nfe-regime` | ⬜ | `"1"`=Simples Nacional, `"2"`=Simples Nacional Excess, `"3"`=Normal | | `tax.ext.br-nfe-fiscal-incentive` | ⬜ | `"1"`=Has incentive, `"2"`=No incentive | **`br-nfe-presence` allowed values:** | Code | Description | NF-e (55) | NFC-e (65) | | ---- | ------------- | --------- | ---------- | | `0` | N/A | ✅ | ❌ | | `1` | In-person | ✅ | ✅ | | `2` | Internet | ✅ | ❌ | | `3` | Tele-service | ✅ | ❌ | | `4` | Home delivery | ❌ | ✅ | | `5` | Off-site | ✅ | ❌ | | `9` | Others | ✅ | ❌ | ```json theme={"system"} "tax": { "ext": { "br-nfe-model": "55", "br-nfe-presence": "1" } } ``` ### Notes At least one note with `key: "reason"` is **required**. It maps to the NF-e `natOp` field (nature of the operation). ### Supplier | Field | Required | Notes | | -------------------------------------- | -------- | --------------------------------------------------------------- | | `name` | ✅ | | | `tax_id.country` | ✅ | `"BR"` | | `tax_id.code` | ✅ | CNPJ (14 digits) or CPF (11 digits), Mod11 validated | | `identities[].key: "br-nfe-state-reg"` | ✅ | State Registration (Inscrição Estadual) | | `addresses` | ✅ | At least one | | `addresses[].country` | ✅ 🔧 | ISO country code. Auto-filled from `tax_id.country` if missing. | | `ext.br-ibge-municipality` | ✅ | 7-digit IBGE municipality code | ### Customer (Model 55 — required, Model 65 — optional) Brazilian customers must provide a Brazilian `tax_id`. Foreign customers can issue an NF-e by providing a country-qualified `identity` (e.g. a passport number) instead of a `tax_id`. | Field | Required | Notes | | ------------------------------------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | `tax_id.country` | ✅ for BR customers | `"BR"` | | `tax_id.code` | ✅ when `tax_id` is present | CNPJ or CPF | | `identities[]` with non-BR `country` | ✅ for foreign customers without a `tax_id` | E.g. `{ "key": "passport", "country": "US", "code": "US-FOREIGN-123" }` | | `addresses` | ✅ | | | `addresses[].country` | ✅ 🔧 | ISO country code. Auto-filled from the `tax_id` country or the first identity that declares a country. | | `addresses[].state` | ✅ for BR customers | Must be a valid Brazilian state acronym (e.g. `SP`). Not required for foreign customers. | | `ext.br-ibge-municipality` | ✅ for BR customers | 7-digit IBGE code. Not required for foreign customers. | ### Line items Required tax categories per line: `ICMS`, `PIS`, `COFINS`. `IPI` is optional. | Extension | Required | Notes | | ---------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `line.ext.br-nfe-cfop` | ✅ model 55
⬜ model 65 | CFOP (Código Fiscal de Operações e Prestações) code identifying the fiscal nature of the operation, e.g. `"5102"` for in-state resale. Required on every line of an NF-e (model 55). | Optional item identities: `item.identities[].key: "ncm" | "gtin" | "gtin+taxable"`. ### Payment Required when the invoice is not fully paid. Must include `payment.instructions.key`. Payment-means mapping is auto-set unless `key: "other"`.
(Corner 5)"] Supplier("👨🏻💼 Supplier
(Corner 1)") Buyer("💁♂️ Buyer
(Corner 4)") AP_S["🌐 Supplier Access Point
(Corner 2)"] AP_B["🌐 Buyer Access Point
(Corner 3)"] Supplier --> AP_S AP_S -- "Invoice" --> AP_B AP_B --> Buyer AP_S -. "Copy to tax authority" .-> IRAS AP_B -. "Copy to tax authority" .-> IRAS classDef tax fill:#fff,stroke:#169958,color:#103830 classDef business fill:#fff,stroke:#169958,color:#103830 classDef ap fill:#fff,stroke:#169958,color:#103830 linkStyle default stroke:#999,font-size:13px,color:#red class IRAS tax class Supplier,Buyer business class AP_S,AP_B ap ``` The five-corner model is not unique to Singapore. Other Peppol jurisdictions, including Malaysia and Australia, are adopting or exploring similar approaches where the national tax authority receives invoice data as an additional corner of the network.
Use the [Create an entry](/api-ref/silo/entries/create-an-entry-put) endpoint to create a new supplier [party](https://docs.gobl.org/draft-0/org/party). The required fields are: * `name` - company name * `tax_id` - tax identification number Set the `folder` parameter to `suppliers` so the entry appears in the suppliers section. The entry will have an `Empty` status initially.
Navigate to **Parties > Suppliers** and click on + New supplier. The following JSON code will appear in the editor: ```json theme={"system"} { "$schema": "https://gobl.org/draft-0/org/party", "name": "", // Name of the company or individual "tax_id": { "code": "", // 11 digit CUIT "country": "" // "AR" } } ``` Fill in the necessary information and click on Build and then Save.
Use the [Create a job](/api-ref/transform/jobs/create-a-job-post) endpoint with the following payload: ```json theme={"system"} // POST https://api.invopop.com/transform/v1/jobs { "workflow_id": "
Open the supplier entry, click Run workflow, and select **Register in ARCA**. The supplier's status will change to `Processing` while awaiting registration completion.
In the Console, open the supplier entry and navigate to the **Meta** tab. Click on **gov-ar.invopop.com** to launch the registration wizard.
To send the registration link to your customer, add a webhook step before **Wait for ARCA certificate upload**. The webhook payload includes the `siloEntryId`. Use the [Fetch an Entry endpoint](/api-ref/silo/entries/fetch-an-entry) to retrieve the full entry, including the `meta` object containing the registration link. ```json Example webhook response expandable theme={"system"} data: { "meta": [ { "id": "...", "created_at": "2025-11-05T15:10:28.132Z", "updated_at": "2025-11-14T15:56:53.727Z", "owner_id": "...", "entry_id": "...", "src": "gov-ar", "key": "link", "ref": "EgDeG3pDBDe", "link_url": "https://gov-ar.invopop.com/reg/EgDeG3pDBDe", "link_scope": "public", "indexed": true, "shared": true } ] } ``` Send the `link_url` to your customer to complete their registration.
Here you will find Senders which were added in the Email app configuration. A sender can be thought of as a person or company name and email address. **To**
Check `Automatically add invoice customers` if you wish to send the invoice as an attachment to the customer. This is usually the case for B2C workflows. If you wish to send the email with attachments to a specific address, tap on the `Add` button and write an address in the email field. You can combine both options: any addresses you add manually are merged with the automatically detected customer or party emails, so all recipients receive the message. **BCC**
BCC stands for *Blind Carbon Copy*, and is used when you do not want the recipients in this field to appear in the message header. Other recipients won't know that a copy was sent to these addresses. This is useful to send a copy of the invoice to yourself, for example. **Reply To**
The "Reply To" field requires a valid email address where recipients' responses will be directed. This field determines where replies go, regardless of the sending address. **Subject**
The email subject field is a brief heading that summarizes your message's purpose. This field allows you to use template variables in order to customize the subject for the recipient.
The email body textarea is where you compose your message's main content. This field allows template variables and will preserve whitespace. **Combine attachments into a single zip file**
It's possible that your workflow generates several files per invoice (sometimes an XML and a PDF file are required by legislation). This option allows you to combine and compress all files into a single `.zip` file. *** ## Custom template variables with job args In addition to the predefined variables available in the **Insert variable** menu, you can inject custom variables into your email templates using job args. This is particularly useful for dynamic content like payment links, conditional text, and other external data. ### How it works When [using the API to run a workflow](/api-ref/transform/jobs/create-a-job-put) you pass an `args` data object with custom variables you want to inject into your email. You will then introduce the variable into the email's subject or body with the following syntax: `{{args.variable_name}}`. If you need to provide a fallback in case the variable is not present, we recommend using the following syntax: `{{ or args.value "Default value" }}`. ### Example: adding a payment link Let's say you want to send an email with a custom payment link. Here's how to set it up:
Besides the supplier's basic information, the entry should contain a `people` object containing a [person](https://docs.gobl.org/draft-0/org/person) who will act as the legal representative of the supplier. 2. [Create a job](/api-ref/transform/jobs/create-a-job-put)`/transform/v1/jobs/{id}`
Using the supplier registration workflow ID and Silo Entry ID. 3. [Generate agreement PDF](/api-ref/apps/gov-es/agreement-fetch) `/apps/gov-es/v1/entry/{silo_entry_id}/sii/agreement`
The agreement file will be created with the supplier's data. 4. [Upload agreement PDF](/api-ref/apps/gov-es/agreement-upload) `/apps/gov-es/v1/entry/{silo_entry_id}/sii/agreement`
Upload the agreement into the supplier's silo entry. 5. [Upload identity images](/api-ref/apps/gov-es/identity-upload) `/apps/gov-es/v1/entry/{silo_entry_id}/sii/identity`
Upload the ID into the supplier's silo entry (can be DNI, NIE or Passport). 6. [Confirm upload](/api-ref/apps/gov-es/confirm) `/apps/gov-es/v1/entry/{silo_entry_id}/sii/confirm`
Call this endpoint to confirm that everything has been prepared correctly and the supplier is ready to start operating. ## Unregister a supplier Unregistering a supplier is essentially revoking their invoice issuing privileges. You might need to unregister an entity because the supplier is no longer your client, because their agreement documentation was rejected, or because of a change in their Tax ID. To do so, use the following workflow template:
Besides the supplier's basic information, the entry should contain a `people` object containing a [person](https://docs.gobl.org/draft-0/org/person) who will act as the legal representative of the supplier. 2. [Create a job](/api-ref/transform/jobs/create-a-job-put)`/transform/v1/jobs/{id}`
Using the supplier registration workflow ID and Silo Entry ID. 3. [Generate agreement PDF](/api-ref/apps/verifactu/agreement-fetch) `/apps/verifactu/v1/entry/{silo_entry_id}/agreement`
The agreement file will be created with the supplier's data. 4. [Upload agreement PDF](/api-ref/apps/verifactu/agreement-upload) `/apps/verifactu/v1/entry/{silo_entry_id}/agreement`
Upload the agreement into the supplier's silo entry. 5. [Upload identity images](/api-ref/apps/verifactu/identity-upload) `/apps/verifactu/v1/entry/{silo_entry_id}/identity`
Upload the ID into the supplier's silo entry (can be DNI, NIE or Passport). 6. [Confirm upload](/api-ref/apps/verifactu/confirm) `/apps/verifactu/v1/entry/{silo_entry_id}/confirm`
Call this endpoint to confirm that everything has been prepared correctly and the supplier is ready to start operating. ## Unregister a supplier Unregistering a supplier is essentially revoking their invoice issuing privileges. You might need to unregister an entity because the supplier is no longer your client or because of a change in their Tax ID. To do so, use the following workflow template:
Registered against the operator's test environment |
Registered against the live operator network | | **Environment** | Operator sandbox | Live operator environment | ## Prerequisites * **The party's details**: legal name, Business ID (*y-tunnus*, e.g. `2617416-4`), and a Finnish address. The Business ID is uploaded without its hyphen as the GOBL `tax_id.code`. * **Reception workflows configured**: registration checks that the Finland app has a sync and an import workflow configured, and fails with "reception not configured" otherwise.
Follow the [receiving guide's setup](/guides/fi-finvoice-receiving#setup) first.
System generates the UUID. * [PUT](/api-ref/silo/entries/files-put) `/silo/v1/entries/{entry_id}/files/{id}`
You specify the UUID. Both endpoints support the same features and parameters. Most applications use `POST` and let the system generate UUIDs. However, `PUT` is useful when you need idempotent operations (safe retries with the same UUID), when integrating with external systems that have their own identifiers, or when you need to reference the file URL before the upload completes. ## Upload options Both endpoints support two upload methods: #### Inline upload (base64) Upload the file data directly in the request body as base64-encoded content. This works well for smaller files. ```bash cURL theme={"system"} curl -X POST 'https://api.invopop.com/silo/v1/entries/{entry_id}/files' \ -H 'Authorization: Bearer YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "name": "invoice.pdf", "category": "format", "mime": "application/pdf", "data": "JVBERi0xLjQKJeLjz9MKMyAwIG9iago8PC9MZW5ndGg..." }' ``` #### Placeholder with streaming upload Create a placeholder file first, then upload the actual file contents to the URL provided in the response. This is useful for larger files or when you want to separate metadata creation from file upload.
e-reporting | | --------------- | ---------------------------------------------------------------- | ------------ | --------------------------------- | | Large | 5,000+ staff, or turnover > €1.5bn / balance sheet > €2bn | 1 Sep 2026 | 1 Sep 2026 | | Mid-sized (ETI) | 250–5,000 staff and turnover €50M–1.5bn / balance sheet €43M–2bn | 1 Sep 2026 | 1 Sep 2026 | | SME (PME) | under 250 staff and turnover \< €50M or balance sheet \< €43M | 1 Sep 2026 | 1 Sep 2027 | | Micro (TPE) | subset of the SME band, at the smallest end | 1 Sep 2026 | 1 Sep 2027 | Because the obligations kick in separately, most SMEs and micro-businesses only need an Annuaire line and an inbox until September 2027 — see [Registering without e-reporting](/guides/fr-pa-registration#registering-without-e-reporting). View our [compliance timeline for France](/timelines/france). ## Key concepts | | | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Annuaire** | The French e-invoicing directory where parties must be registered to participate in regulated e-invoicing flows. Not to be confused with the Peppol Directory. | | **PPF** | Portail Public de Facturation — the French government system that receives mandatory invoice data and lifecycle updates. Invopop handles all communications with the PPF automatically. | | **Regulated Flow** | An invoice exchange where both the sender and receiver are registered in the Directory. These follow the complete French e-invoicing process including Peppol transmission and PPF reporting. | | **Non-Regulated Flow** | An invoice exchange where only one party is registered in the Directory. Invoices are stored for e-reporting to the PPF but may not be transmitted via Peppol. | | **E-reporting** | Periodic reporting to the PPF covering non-regulated flows and B2C transactions. | | **CDAR** | Cross Domain Acknowledgement and Response. The format used for lifecycle status updates ("cycle de vie") in France, communicated between parties and to the PPF. | | **Fifth Corner** | The tax authority in the Peppol exchange model. Corners 1–4 are sender, sender's PA, receiver's PA, and receiver; the fifth corner is the tax authority that receives a copy of the invoice for regulated flows. In France this is the PPF. | | **F1 Invoice** | Simplified UBL format used to forward the invoice to the fifth corner (the tax authority, i.e. the PPF) for regulated flows. Part of e-invoicing, not e-reporting. Generated automatically by Invopop. | ## Flows and obligations In France's e-invoicing reform, "flux" are the officially numbered message flows defined in the external specifications that structure how invoices and tax data move between businesses, their plateformes agréées (PAs), and the administration. This table presents the flows relevant to an integration with Invopop: | Flux | What it carries | Guide | | ------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------ | |
[Status](/guides/fr-pa-status) | | French company → EU company |
by the French buyer | | Foreign company (non-EU) → French company |
by the French buyer | | French company → French non-taxable legal person (not VAT-registered) |
by the foreign seller | | French company → French public entity (B2G) | Chorus Pro circuit | [Chorus Pro](/guides/fr-chorus-pro) | ## Mandatory mentions Beyond the usual invoice data (parties, dates, line detail, VAT), the reform adds four *nouvelles mentions obligatoires* that every domestic B2B e-invoice must carry from 1 September 2026. | Mention | GOBL field | Notes | | --------------------------------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Buyer's SIREN**
(SIRET where the establishment matters) | `customer.tax_id` and `customer.identities[]` | Provide the `SIREN` or `SIRET` identity. Required for routing and enforced by `BR-FR-10/11`. | | **Delivery address** (country/address, when it differs from billing) | `delivery.receiver.addresses[]` | Required when the place of delivery differs from the customer's billing address. Omit it when they are the same. | | **Nature of the operation** (goods / services / both) | `tax.ext.fr-ctc-billing-mode` | Mandatory classification between `B*` = goods, `S*` = services or `M*` = mixed. | | **VAT on debits** (paiement de la TVA d'après les débits, when opted) | `tax.notes[]` with key `tax` | Carried as a legal-mention note. Add it only when the supplier has opted for VAT on debits. | ## FAQ Consult our [France FAQ](/faq/france) section. ***
Summary per kind (current window, next deadline, last filed report)
Paginated history of filed periods (filter with `?kind=tx` or `?kind=py`)
A single period's metadata
The raw report XML sent to the PPF ## FAQ
Déposée / Deposited | — | Emitted when the invoice is deposited on the platform. | |
Émise par la plateforme / Issued by platform | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Emitted when the platform transmits the invoice. You may receive it on the buyer side — no action needed. | |
Rejetée / Rejected by platform | — | Emitted when a platform rejects the invoice on validation. | ### Issued by the buyer | Status | Document | Notes | | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | |
Reçue par la PA / Received by recipient | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Acknowledge that the invoice has been received. | |
Mise à disposition / Made available | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. The invoice has been made available to the buyer. | |
Prise en charge / Taken into account | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Signal that the invoice is being processed. | |
Approuvée / Approved | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Approve the invoice in full. | |
Partiellement approuvée / Partially approved | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Approve part of the invoice; requires a [reason](#available-reasons-for-codes), typically with an `action` requesting a partial credit note. | |
En litige / Disputed | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Dispute the invoice; requires a [reason](#available-reasons-for-codes). | |
Suspendue / Suspended | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Pause processing while the supplier provides missing information; requires a [reason](#available-reasons-for-codes). | |
Refusée / Refused by buyer | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | **Mandatory** when refusing an invoice; requires a [reason](#available-reasons-for-codes). Forwarded to the PPF. | |
Paiement transmis / Payment advice | [bill/payment](https://docs.gobl.org/draft-0/bill/payment#payment) | Optional. Notify the supplier that a payment has been sent. | ### Issued by the supplier | Status | Document | Notes | | ------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------ | |
Complétée / Completed | [bill/status](https://docs.gobl.org/draft-0/bill/status#status) | Optional. Lift a `208` suspension by supplying the requested data. | |
Encaissée / Cashed | [bill/payment](https://docs.gobl.org/draft-0/bill/payment#payment) | **Mandatory** when the invoice is paid. Forwarded to the PPF. | ## Invoice lifecycle After an invoice is issued it moves through a sequence of lifecycle events. Each event is a [GOBL status](https://docs.gobl.org/draft-0/bill/status) or [GOBL payment](https://docs.gobl.org/draft-0/bill/payment) that references the invoice and carries one CDV `ProcessConditionCode`. For the full list of codes see [Status codes](#status-codes). The paths below are **common examples, not an exhaustive set**: any code can in principle follow another (e.g. a
Issued
↓
Received
↓
Made available
↓
Taken into account
↓
Approved
↓
Payment advice
↓
Receipt |
Issued
↓
Received
↓
Partially approved
↓
Receipt |
Issued
↓
Received
↓
In dispute
↓
Suspended
↓
Completed
↓
Approved
↓
Receipt | ```mermaid theme={"system"} flowchart LR S201[201 issued] --> S202[202 received] S202 --> S203[203 made available] S203 --> S204[204 taken into account] S204 --> S205[205 approved] S202 --> S206[206 partial] S202 --> S207[207 dispute] S202 --> S210[210 refused] S207 --> S208[208 suspended] S208 --> S209[209 completed] S209 --> S205 S205 --> P211[211 advice] P211 --> P212[212 receipt] S206 --> P212 ``` ## Workflows
SDI has rejected the invoice because it contains errors. | | `delivered` | **Ricevuta consegna (RC)**
SDI has successfully delivered a B2B invoice to the recipient. | | `delivered-pa` | **Ricevuta consegna (RC)**
SDI has successfully delivered an invoice to a Public Administration (PA). | | `not-delivered` | **Mancata consegna (MC)**
SDI could not deliver the invoice to the recipient. | | `not-delivered` | **Attestazione trasmissione con impossibilità di recapito (AT)**
SDI couldn't deliver an invoice to PA after 10 days. | | `accepted-pa` | **Notifica esito (NE)**
A PA has decided to accept an invoice (outcome EC01). | | `rejected-pa` | **Notifica esito (NE)**
A PA has decided to reject an invoice (outcome EC02). | | `deadline-terms` | **Notifica decorrenza termini (DT)**
A PA didn't reply with acceptance or rejection within 15 days. | | `invoice-error` | An error occurred during the acquisition of a notification. | | `sent` | The invoice has been submitted to SDI and is awaiting a response. | | `not-received` | The invoice was not received by the recipient. | Some SDI notifications (File metadati - MT, Esito committente - EC, Scarto esito committente - SE) don't directly change the code of the invoice. These codes map to different step results as follows: * **OK Result**: `delivered`, `not-delivered`, `not-received`, `accepted-pa` * **KO Result**: `rejected`, `rejected-pa`, `invoice-error`, `deadline-terms` * **QUEUED Result**: `sent`, `delivered-pa` When a step returns `QUEUED`, the workflow will check again later for updates from SDI.
- `A4`: used in Europe and various other countries.
- `Letter`: used in United States, Canada, Mexico, Philippines, and other countries in Latin America.
- `DIN5008`: used in Germany as the standard for documents that will present information within an envelope window. If you select this option, the customer's information (name and address) will be placed within this window.
Test mode | **Test Polish Tax ID (NIP)**
You can generate fake NIPs for testing at [http://generatory.it/](http://generatory.it/). In test mode, a self-signed certificate will be generated automatically, and you can start sending invoices immediately.
| |
Demo mode | **Real Polish Tax ID (NIP) and credentials to access the [KSeF Demo Portal](https://ap-demo.ksef.mf.gov.pl/web/)**
Demo mode follows the same registration process as production but operates in the demo environment. | |
You will need to generate a certificate through the KSeF portal. Registration will automatically target the KSeF production environment. | ## Setup All of the following steps must be carried out from the [Invopop Console](https://console.invopop.com).
In Console, go to the supplier entry → **Meta** tab → click the **gov-pl.invopop.com** link to launch the registration wizard.
Add a webhook after the **Register supplier with KSeF** step to receive the `siloEntryId`. Use the [Fetch an Entry endpoint](/api-ref/silo/entries/fetch-an-entry) to get the registration link from the `meta` object: ```json theme={"system"} { "data": { "meta": [ { "src": "gov-pl", "key": "link", "link_url": "https://gov-pl.invopop.com/reg/AbC123XyZ" } ] } } ``` Send the `link_url` to your customer.
Return to the registration wizard and upload: * Certificate file * Private key file * Password
Upload the certificate programmatically using the [Upload KSeF certificate endpoint](/api-ref/apps/gov-pl/certificate-upload).
*(Formação)* | `F` | For testing and training purposes only. Documents issued under a training series are fictitious and carry no fiscal effect. Use this type in sandbox workspaces when validating your integration before going live. | | **Recovery**
*(Recuperação)* | `R` | A special type for registering documents that were issued manually on paper during a system outage. Portuguese law requires that when the invoicing system is unavailable, issuers continue on paper and then re-enter those documents once the system is restored. See [Recovering documents issued offline](/guides/pt-at#recovering-documents-issued-offline) for the full process. |
- AUD
- BGN
- BRL
- CAD
- CHF
- CNY
- CZK
- DKK
- EUR
- GBP
- HKD
- HUF
- IDR
- ILS
- INR
- ISK
- JPY
- KRW
- MXN
- MYR
- NOK
- NZD
- PHP
- PLN
- RON
- SEK
- SGD
- THB
- TRY
- USD
- ZAR
The endpoint that will receive the `POST` request. **Event (optional)**
Specify a custom event name such as `success`, `error`, or `invoice_sent`. This will appear under the `event` field in the JSON payload. **Authentication Bearer Token (optional)**
If your endpoint requires authorization, include a token here. The request will include a header: `Authorization: Bearer
Add one or more HTTP headers. This is useful for services that require API keys, content types, or verification signatures. **Sample Body**
Below is an example of the JSON payload that will be sent: ```json theme={"system"} { "id": "", "event": "", "transform_job_id": "", "silo_entry_id": "", "owner_id": "", "key": "", "args": {}, "faults": [] } ``` * `id` the id of the webhook event. * `event` custom event name set up in the step (if any). * `transform_job_id` the id of a job run through the [Transform Job endpoint](/api-ref/transform/jobs/fetch-a-job-by-key) * `silo_entry_id` the id of the [silo entry](/api-ref/silo/entries/fetch-an-entry) * `key` the job's [key](/api-ref/transform/jobs/create-a-job-put#body-key) to ensure [idempotency](/api-ref/idempotency). * `args` certain workflow steps can add data to the args field which is then made available to subsequent steps and to webhook payloads. * `faults` array of [fault](/api-ref/transform/jobs/fetch-a-job#response-faults) objects that represent errors that occurred during the processing of the job.
Existing systems enforced in Argentina regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | | [Factura Electrónica](/compliance/argentina) | Argentina's mandatory electronic invoicing system, used to record, validate, and report all taxable transactions to ARCA in real time through a clearance model. | [Yes](/apps/argentina) |
[Mandate 5782 / 2025](https://www.argentina.gob.ar/normativa/nacional/resolución-5782-2025-419496/texto) comes into effect, with [CAE](https://servicioscf.afip.gob.ar/publico/comprobantes/cae.aspx) as the default real-time system. CAEA (the previous default batch reporting system) will only be used as a fallback when online systems are unavailable. The resolution now makes C.A.E. (Código de Autorización Electrónico) the default standard.
From January 1st 2026, all invoices must be delivered in the `EN 16931` electronic format. Even though legislation doesn't mention Peppol, in practice it's the only compliant network in Belgium. Businesses supplying the public sector are already required to issue EN 16931 electronic invoices when the contract meets the criteria. | System | Description | Invopop Coverage | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [Peppol](/compliance/belgium) | Peppol is a standardized European network that enables the secure exchange of electronic business documents—such as invoices—between organizations using interoperable formats and certified access points. For B2G transactions in Belgium, invoices are routed through Mercurium transparently. | Yes |
Belgium plans to complement the e-invoicing mandate with an electronic reporting (e-reporting) regime enabling near-live data transmission.
Belgium may extend real-time e-reporting or e-invoicing to all domestic and cross-border sales as part of the EU **VAT in the Digital Age (ViDA)** initiative.
Existing systems enforced in Brazil regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | ------------------------------------------------------------------------------ | ---------------------------------------------- | ------------------------ | | [Documentos Fiscais Eletrônicos](/apps/documentos-fiscais-electronicos-brazil) | Brazil's mandatory electronic invoicing system | Yes (NF-e, NFS-e, NFC-e) | | SPED | Brazil's mandatory e-reporting system | No |
Existing systems enforced in Colombia regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [FEV](/compliance/colombia) | Colombia's mandatory electronic invoicing system, used to record, validate, and report all taxable transactions to the DIAN in real time. | Yes |
Croatia's **Fiscalization 2.0** (eRačun) is live since 1 January 2026. VAT-registered businesses must exchange structured e-invoices with their partners and report each invoice to the tax authority in real time. Consumer sales stay on the older receipt system. | System | Description | Invopop coverage | | ------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------- | | [eRačun (Fiscalization 2.0)](/compliance/croatia) | Structured e-invoicing over a 4-corner network, with reporting to the tax authority | Work in progress |
Croatia's Fiscalization Act comes into force, setting the framework for structured e-invoicing and real-time reporting.
VAT-registered Croatian businesses must issue and receive domestic e-invoices and report each one to the tax authority. Consumer receipt fiscalization is extended to all payment methods.
Businesses that are not VAT-registered, and public bodies, must also be able to issue e-invoices.
The EU's VAT in the Digital Age initiative is expected to introduce harmonized digital reporting across member states.
Denmark became the first country in Europe to mandate electronic invoicing to public authorities. | System | Description | Invopop Coverage | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [NemHandel / OIOUBL](/compliance/denmark) | Electronic invoicing to all Danish public authorities via NemHandel, using the OIOUBL format. Mandatory since February 2005. | Yes | | [Peppol BIS Billing 3.0](/compliance/denmark) | From April 2019, all public authorities must also accept invoices compliant with the EU standard EN 16931 via Peppol. | Yes |
Denmark's 2022 Bookkeeping Act requires businesses to use certified digital bookkeeping systems capable of issuing and receiving structured e-invoices (Peppol BIS 3.0 and OIOUBL) and generating SAF-T files on demand. | Phase | Scope | Date | | ------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------- | | Phase 1 | Medium/large companies (classes B, C, D) using certified standard systems | 1 Jul 2024 | | Phase 2 | Same companies using custom/self-developed systems | 1 Jan 2025 | | Phase 3 | All businesses with turnover > DKK 300,000 for two consecutive years, incl. foreign entities with Danish VAT registration | 1 Jan 2026 | | Phase 4 | Remaining businesses using in-house developed systems | No earlier than 1 Jul 2026 |
Schematron validation rules v1.17 for OIOUBL 2.1 become mandatory for all B2G e-invoicing. This follows the January 2026 cancellation of OIOUBL 3.0, with Denmark now converging on a single Peppol-aligned standard.
Denmark is expected to introduce a domestic digital reporting requirement for B2B transactions, potentially replacing the annual VAT client listing. The Bookkeeping Act already authorizes the government to establish a common public data reception for e-documents, laying the groundwork for a future continuous transaction control (CTC) model.
Following the cancellation of OIOUBL 3.0 in January 2026, Erhvervsstyrelsen is developing a single unified standard to replace the current dual-format landscape (OIOUBL 2.1 + Peppol BIS 3.0). This is likely to be based on Peppol PINT or a Danish National CIUS of EN 16931. Details and timelines will be published once the technical specification is finalized.
The EU ViDA Directive (adopted March 2025) requires mandatory e-invoicing and digital reporting for all intra-EU B2B transactions. Denmark, as an EU member state, must comply by this date. This is expected to accelerate the introduction of a domestic B2B e-invoicing transmission mandate ahead of the deadline.
Central government has received e-invoices since 1 April 2019, extended to all contracting authorities from 1 April 2020, both under Act 241/2019 (implementing EU Directive 2014/55/EU). Since 1 April 2021, public bodies may only accept EN 16931-compliant invoices. The Finnish State Treasury (Valtiokonttori) has been Finland's national Peppol Authority since 2022, and central government purchases have required Peppol e-ordering since 1 April 2024. B2B e-invoicing remains voluntary, but businesses with turnover above EUR 10,000 have a statutory right to request e-invoices from their suppliers. | System | Description | Invopop Coverage | | ------------------------------------------------------------------------------------ | -------------------------------------------------------------- | ----------------------------- | | [Peppol](/compliance/finland#peppol-network-b2g) | B2G e-invoicing (and voluntary B2B) through the Peppol network | Yes | | [Finvoice / TEAPPSXML](/compliance/finland#domestic-channels-finvoice-and-teappsxml) | Domestic bank/operator channels for recipients outside Peppol | Roadmap, confirm with support |
Act 241/2019 (Act on Electronic Invoicing to Public Procurers and Contracting Entities) takes effect, requiring central government bodies to receive electronic invoices.
All Finnish public contracting authorities must now receive e-invoices. In parallel, businesses with an annual turnover above EUR 10,000 gain a statutory right to request e-invoices from their suppliers.
Public bodies may only accept invoices compliant with the EN 16931 European standard, tightening the April 2019/2020 mandate.
The Finnish State Treasury (Valtiokonttori) takes over as Finland's Peppol Authority, managing SMP registration for Finnish participants.
Central government purchases must be ordered through Peppol e-ordering documents in addition to e-invoicing.
The EU's VAT in the Digital Age (ViDA) initiative is expected to introduce harmonized Digital Reporting Requirements across member states, extending real-time e-reporting obligations to Finland's intra-EU B2B transactions.
Businesses can voluntarily participate in the pilot phase to test B2B e-invoicing systems before the mandatory rollout begins.
Existing systems enforced in France regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [Chorus Pro](/compliance/france) | All suppliers invoicing French public entities must submit electronic invoices through Chorus Pro, a mandatory service provided by the French government | Yes | | [Peppol](/compliance/france) | B2G e-invoicing through the Peppol network for businesses invoicing public authorities | Yes |
All businesses must be able to receive e-invoices. Large and medium-sized companies (more than 250 employees and exceeding either €50 million in turnover or €43 million in balance sheet) must issue e-invoices. E-reporting of issued transactions (B2C sales and cross-border B2B) becomes mandatory for these companies.
All remaining businesses (small and micro-businesses) must issue e-invoices. E-reporting of issued transactions (B2C sales and cross-border B2B) becomes mandatory for all businesses.
Non-established taxable persons must start e-reporting of acquisitions, regardless of the size of the business. This obligation is postponed from 1 September 2026 so that it applies to all non-established taxable persons on the same date.
B2G invoices require sending through the Peppol network in the XRechnung format. In B2B, all German businesses must be able to receive e‑invoices in a structured format complying with the European standard EN 16931.
Businesses with annual turnover above €800,000 must issue e‑invoices in the structured format (i.e., move away from paper or unsecured electronic formats).
The requirement to issue structured e‑invoices extends to all businesses for domestic B2B transactions.
Existing systems enforced in Greece regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [EN 16931](/compliance/greece) | All public sector entities are required to receive and process structured eInvoices compliant with the European standard EN 16931 | Yes | | [myDATA reporting](/compliance/greece) | From Jan 1, 2024, all companies must declare their sales invoices (Accounts Receivable) in real-time to the myDATA platform | Yes |
Companies with revenues exceeding €1 million in the 2023 fiscal year in Greece will be required to issue electronic invoices for the sale of goods and provision of services within the country, as well as for transactions with companies from third countries (outside the European Union)
Greece's B2B invoicing mandate phases in smaller companies' obligations by October 2026.
Greece has expressed strong interest in extending real-time e-reporting or e-invoicing to all domestic and cross-border sales as part of the EU VAT in the Digital Age (ViDA) initiative.
* Business-to-Government (B2G): All suppliers to public authorities must send electronic invoices. This has been in place since 2014-2015 and is enforced through the Sistema di Interscambio (SDI) platform. * Business-to-Business (B2B): Since 1 January 2019, all VAT-registered businesses must issue eInvoices via SDI. * Business-to-Consumer (B2C): Also mandatory from 2019 for transactions with consumers. | System | Description | Invopop Coverage | | ---------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------ | | [SDI](/apps/sdi-italy) | Italy's mandatory electronic invoicing system | [SDI](/apps/sdi-italy) (B2B, B2G)
[Smart Receipts](/apps/smart-receipts-italy) (B2C) |
Italy's derogation from the EU VAT Directive expires; the SDI regime is expected to be adapted to align with the EU's ViDA requirements.
Existing systems enforced in Mexico regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [CFDI](/compliance/mexico) | Mexico’s mandatory electronic invoicing system, used to record, validate, and report all taxable transactions to the SAT in real time. | Yes |
Norway currently enforces mandatory B2G e-invoicing through Peppol, SAF-T Financial v1.30 for bookkeeping-obligated businesses with electronic accounting data, and digital VAT return filing through *mva-meldingen*. | System | Description | Invopop Coverage | | -------------------------------------------- | ------------------------------------------------------------------------------------------------ | ---------------- | | [Peppol BIS Billing 3.0](/compliance/norway) | Mandatory for all suppliers to the public sector | Yes | | [SAF-T Financial](/compliance/norway) v1.30 | Mandatory audit file format for bookkeeping-obligated businesses with electronic accounting data | No | | [mva-meldingen](/compliance/norway) | Mandatory digital VAT return via Altinn, aligned with SAF-T tax codes | No |
The Norwegian Ministry of Finance has proposed that all businesses with bookkeeping obligations must send e-invoices in Peppol BIS Billing 3.0 format to recipients registered in ELMA. Consultation closed 31 October 2025 — final legislative decision pending.
All businesses with bookkeeping obligations would also be required to receive e-invoices and maintain digital bookkeeping systems. This aligns with the EU's ViDA cross-border deadline, reflecting Norway's deliberate alignment with European norms despite not being an EU member state.
Norway is not directly bound by the EU's **VAT in the Digital Age (ViDA)** initiative (formally adopted 11 March 2025), but as an EEA member the directive is likely to be deemed EEA-relevant and incorporated via Joint Committee decision. Norway's proposed B2B mandate timeline is explicitly designed to align with ViDA's 2030 cross-border deadline.
Existing systems enforced in Portugal regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | -------- | ------------------------------------------------------------- | ---------------- | | QR/ATCUD | Invoices are required to have an ATCUD and QR Code | Yes | | SAF-T | E-reporting required either in real-time or via SAF-T reports | Yes | | CIUS-PT | B2G XML invoice format | No |
Companies in Portugal that issue PDF invoices will be required to include a Qualified Electronic Signature (QES) that confirms the authenticity and integrity of the document.
Portugal may extend real-time e-reporting or e-invoicing to all domestic and cross-border sales as part of the EU VAT in the Digital Age (ViDA) initiative.
Phase 2 introduces a continuous transaction control model and is rolled out in turnover-based waves. All in-scope taxpayers must integrate their e-invoicing solutions with ZATCA's Fatoora platform and produce UBL 2.1 invoices aligned with EN 16931, signed with a ZATCA-issued Cryptographic Stamp Identifier (CSID) using a XAdES digital signature, with a UUID, hash chain and TLV-encoded base64 QR code. Two flows apply: | Flow | Applies to | Mechanism | | ------------------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Clearance](/compliance/saudi-arabia) | B2B and B2G standard tax invoices | The invoice is submitted to Fatoora and cryptographically stamped by ZATCA *before* being issued to the buyer. Without clearance, the invoice is not valid. | | [Reporting](/compliance/saudi-arabia) | B2C simplified tax invoices | The invoice is issued to the customer at point of sale with its QR code and reported to Fatoora within 24 hours. | Wave 1 covered taxpayers with turnover above SAR 3 billion in 2021. Subsequent waves have progressively lowered the threshold, with ZATCA notifying each wave at least six months before its integration deadline.
Taxpayers with VAT-taxable turnover exceeding SAR 375,000 in 2022, 2023 or 2024 must integrate their e-invoicing systems with the Fatoora platform by 30 June 2026. This is the first wave to drop the threshold below SAR 750,000 and brings a large share of the Saudi SME population into Phase 2. Further waves are expected to be announced as ZATCA progressively extends the mandate to smaller taxpayers.
Existing systems enforced in Singapore regarding e-invoicing and e-reporting. | System | Description | Invopop Coverage | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | [GST InvoiceNow Requirement](/compliance/singapore) | Peppol-based e-invoicing and near real-time reporting to IRAS. Mandatory for newly incorporated companies that voluntarily register for GST. | Coming soon | | [GST F5 Reporting](/compliance/singapore) | Quarterly aggregate GST return filed via IRAS myTax Portal. Mandatory for all GST-registered businesses. | Coming soon |
All businesses that voluntarily register for GST from this date must comply with the GST InvoiceNow Requirement, regardless of business type or incorporation date. | System | Description | Invopop Coverage | | --------------------------------------------------- | ------------------------------------------------ | ---------------- | | [GST InvoiceNow Requirement](/compliance/singapore) | Mandatory for all new voluntary GST registrants. | Coming soon |
IRAS has confirmed the mandate will extend to new compulsory GST registrants and eventually all existing GST-registered businesses in subsequent phases. Specific dates have not yet been published.
Existing systems enforced in Spain regarding e-invoicing, e-reporting and fiscalization. | System | Description | Invopop Coverage | | -------------------------------------------- | ------------------------------------------------------------------------ | ---------------- | | [Facturae](/compliance/spain)
via FACe | XML-based format for B2G invoices used on the government's FACe platform | Yes | | [SII](/compliance/spain) | Near real-time reporting for B2B companies above €6M annual turnover | Yes | | [TicketBAI](/compliance/spain) | The Basque Country's B2B invoicing and anti-fraud system | Yes |
Spain's regulation developing the mandatory B2B e-invoicing system between businesses and professionals (Ley Crea y Crece) was published in the BOE on 31 March 2026 and entered into force on 20 April 2026. Effective dates for businesses depend on the upcoming Orden Ministerial.
The technical Orden Ministerial that will start the rollout clock. Currently in draft (public consultation closed 8 May 2026). Once it enters into force, the 12- and 24-month deadlines below begin counting.
Companies must start using certified invoicing systems to issue and report invoices to AEAT under the VERI\*FACTU framework. | System | Description | Invopop Coverage | | -------------------------------- | ------------------------------------------------------------------------------------- | ---------------- | | [VERI\*FACTU](/compliance/spain) | Certified invoicing software with digitally signed invoices and reporting to the AEAT | Yes |
Deadline for self-employed individuals and other companies (that are not subject to Corporate Tax) to implement the VERI\*FACTU system.
Companies with annual turnover above €8M must issue and receive structured electronic invoices through the new "sistema español de factura electrónica" — either via private interoperable platforms or via the AEAT's free Solución Pública. During the first year, invoices must also be accompanied by a legible PDF unless the recipient agrees otherwise. This is not related to VERI\*FACTU. | System | Description | Invopop Coverage | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | Solución Pública / Plataformas privadas | EN 16931–compliant exchange (Facturae, UBL/Peppol BIS, CII, EDIFACT). Private platforms must send a UBL "copia fiel" to the AEAT Solución Pública at issuance. | TBD |
All other businesses, self-employed professionals, and FACeB2B subcontractors of public-sector contracts must comply. Self-employed individuals (personas físicas) get an additional 12 months (until \~Oct 2029) to comply with the obligation to report invoice states.
Without any deadlines, Navarra's tax agency announced in September 2025 the implementation of NaTicket for their territory. It will be analogous to TicketBAI and VERI\*FACTU.
Spain may extend real-time e-reporting or e-invoicing to all domestic and cross-border sales as part of the EU **VAT in the Digital Age (ViDA)** initiative.