Document types and type codes

Every invoicing format uses type codes to identify what kind of document is being sent. Maventa processes these codes during import and export, and automatically converts between format-specific codes when converting documents from one format to another.

This page covers the most commonly used formats. Maventa supports additional formats beyond those listed here.

How document types work

Each format has its own way of indicating the document type:

• UBL-based formats (Peppol BIS, EHF, OIOUBL, SI-UBL) use the XML root element to determine the document type. An <Invoice> element means it is an invoice, a <CreditNote> element means it is a credit note. The InvoiceTypeCode field provides additional detail (the subtype) but does not change the document type.
• Finvoice uses the InvoiceTypeCode element (INV01, INV02, etc.) to determine both the document type and subtype. Codes not in the supported list are rejected.
• TEAPPS uses the INVOICE_TYPE field with numeric codes. Codes not in the supported list are rejected.

Finvoice

Finvoice 1.3 supports invoice and credit note. Versions 2.0 and later add direct payment and cancel.

Default export codes: INV01 for invoices, INV02 for credit notes and cancellations, INV09 for direct payments.

Secure invoices (SEI codes)

Each INV code has a corresponding SEI (Secure E-Invoice) counterpart. Secure invoices are processed as the same document type as their INV equivalent, with an additional security classification flag.

The security classification is preserved during conversion between Finvoice and TEAPPS. When converting to any other format, the security classification is lost and the document is treated as a standard invoice or credit note. See Secure invoice conversion behavior for details.

TEAPPS

TEAPPS 2.7.2 supports invoice and credit note. Version 3.0 adds direct payment and cancel.

Default export codes: 00 for invoices, 01 for credit notes.

TEAPPS does not have dedicated security invoice type codes. Instead, TEAPPS 3.0 carries security classification in a separate SECURITY_DETAILS element with a SECRECY_CLASS code and an optional SECRECY_DESCRIPTION. When a Finvoice secure invoice (SEI code) is converted to TEAPPS, the invoice type code is mapped to the standard TEAPPS equivalent and the SEI code is stored in SECRECY_CLASS. See Secure invoice conversion behavior for details.

Peppol BIS 3.0

Peppol BIS 3.0 uses UNCL 1001 invoice type codes. The table below lists the most commonly used codes. The full code list is defined in the Peppol BIS 3.0 specification and evolves over time — some codes may have country-specific restrictions or conditions.

Default export codes: 380 for invoices, 381 for credit notes.

OIOUBL (Danish)

Both versions 2.02 and 2.1 support the same types.

Also supports application_response as a separate document type.

Default export codes: 380 for invoices, 381 for credit notes.

SI-UBL 2.0 (Dutch)

Subtype preservation during format conversion

When Maventa converts a document from one format to another, the document type (invoice, credit note) is always preserved. However, the specific subtype (such as Reminder Invoice or Interest Note) is only preserved if the target format recognizes the same subtype. If the target format does not have a matching subtype, the type code falls back to the default for that document type.

Default fallback codes

Cross-format subtype compatibility

The following table shows which subtypes are shared between format families. A subtype is preserved during conversion only if both the source and target format define it.

The “Content” column indicates whether the document content associated with that subtype (such as factoring details or overdue payment data) can be carried in the target format’s payload, even when the type code itself falls back to a generic value.

A dash (—) in the type code columns means the format does not have a dedicated type code for that subtype. When converting to a format that shows a dash, the type code falls back to the default (Commercial Invoice or Credit Note). However, the document content may still be converted if the target format supports the relevant payload fields.

Conversion examples

Secure invoice conversion behavior

Finvoice secure invoices (SEI codes) carry a security classification that indicates the document requires special handling. This classification is a feature specific to the Finnish invoicing ecosystem and is only fully supported in Finvoice and TEAPPS formats.

Finvoice to Finvoice: The SEI code is passed through as-is. A document sent as SEI05 (Secure Collect Note) is delivered as SEI05.

Finvoice to TEAPPS: The security classification is preserved as separate metadata. The invoice type code is mapped to the corresponding non-secure TEAPPS equivalent (for example, SEI05 maps to TEAPPS code 02, which is the Collecting Invoice). The security information travels alongside the document so it can be restored if the document is later converted back to Finvoice.

TEAPPS to Finvoice: If the TEAPPS document carries security metadata, the converter restores the SEI code in the Finvoice output. For example, a TEAPPS document with code 02 and a stored security code of SEI05 is exported as Finvoice SEI05.

Finvoice or TEAPPS to any other format: The security classification is lost. The document is converted using the underlying invoice subtype only (for example, SEI05 becomes a standard Commercial Invoice with code 380 in Peppol BIS 3.0). There is no mechanism to carry the security classification in UBL or other non-Finnish formats.

Content-level feature support

The type code tells the recipient what kind of document it is, but the actual data that makes a document special is carried in the document content. For example, a factored invoice contains factoring party details and bank accounts in its payload. When converting between formats, Maventa maps this content independently of the type code. Even if the target format does not have a dedicated type code for “factored invoice”, the factoring data is still converted if the target format has the relevant fields.

The following tables show which formats can carry specific content features in their payload. This is separate from whether the format has a dedicated type code for that feature.

Factoring and payee party

Factoring information identifies a third party (the factor) who receives payment on behalf of the seller. This data includes the factoring party name, address, bank accounts, and agreement details.

Overdue payment and interest calculation details

Interest invoices and collect notes typically carry per-row details about the original overdue invoices: original invoice number, dates, amounts, interest rate, interest period, and calculated interest charges.

Penalty interest rate

A header-level interest rate that applies to late payments. This is a simpler field than the row-level overdue payment details above.

Prepaid amount

The amount already paid before the invoice is issued, used for advance payments and prepayment invoices.

Direct payment

Direct payment (suoramaksu) is a Finnish payment method where the invoice amount is collected directly from the payer’s bank account. This is a concept specific to the Finnish invoicing ecosystem.

Self-billing

Self-billing is when the buyer creates the invoice on behalf of the seller. Beyond the type code, this requires reversing the party roles (the buyer becomes the accounting supplier).

Construction invoice specifics

Construction invoices (type codes 875, 876, 877) are distinguished only by their type code. No format has construction-specific payload fields such as completion percentage or site details. The only related structural element is the standard contract reference field, which is available in most formats.