Invoice XML & content

XML in e-invoicing

XML presents invoice data in a structured way. Maventa e-invoicing supports wide variety of XML based standard invoice formats and automatically converts the invoices from one format to another when needed. See the supported formats and xml examples below.

Supported XML formats

See all example XML files from here.
Please notice that Finvoice examples have two different files, one uses SOAP envelope and one uses MessageTransmissionDetails. Finvoice 2.0 has also version 2.01.

Supported attachment filetypes

  • .tif
  • .tiff
  • .jpg
  • .jpeg
  • .png
  • .gif
  • .txt
  • .xml
  • .xls
  • .xsl
  • .xlsx
  • .html
  • .htm
  • .pdf
  • .aix
  • .doc
  • .docx
  • .ods

These are the attachment types supported by Maventa SOAP and REST API.

Note that there might be also format and operator specific limitations. Remember check limitations from format’s documentation, e.g. PEPPOL support only these MimeCodes.

Invoice Image handling (Example PDF with Modern template)

When sending e-invoices, a PDF version of the invoice is always sent and if no such PDF exists, it will be created using Maventa PDF templates. It is recommended that ERP generates and sends the invoice image in PDF format with the XML, in that way the user knows which template will be used for PDF viewing of the invoice.

The image can be sent as embedded attachment within xml or within a zip file depending on the invoice format that is used. If the invoice image is sent as an attachment within a zip file, the invoice xml and invoice image file within the zip need to be named the same way for Maventa to recognize the attachment as the invoice image. For example 12345.xml and 12345.pdf.

PDF is filled with corresponding Finvoice tags to make it clear which tag is visualised where.
Note! If all the address details are given the PDF will easily expand to two or more pages.

Download fullsize image

Note! Information given in <SpecificationDetails> -element (<SpecificationFreeText> tags) have different font. The font is Courier (all the characters are equally wide). The purpose of using this font type in this case is to keep the formatted text as it is given in the XML.

Example usage of <SpecificationDetails> -element

	<SpecificationFreeText>LASKUN VAPAAMUOTOISET ERITTELYTIEDOT:</SpecificationFreeText>
	<SpecificationFreeText>Sarake-1              Sarake-2                                                             Sarake-3</SpecificationFreeText>
	<SpecificationFreeText>1.sarakkeen tieto     2.sarakkeen tieto                                                       10,00</SpecificationFreeText>
	<SpecificationFreeText>Toinen rivi           Toinen rivi                                                          1 000,00</SpecificationFreeText>
	<SpecificationFreeText>Kolmas rivi           3/2                                                                      1,00</SpecificationFreeText>
	<SpecificationFreeText>Muotoituja tietoja voidaan käyttää mm.tarkemman erittelyn esittämiseen:</SpecificationFreeText>

SpecificationDetails example

Invoice validation & Autovalidator

Before invoices are sent there are certain validations made to ensure that the invoice XML contains the necessary data and is set up correctly. The validation requirements depend on where the invoice is sent to. Some of the routes such as Peppol network, require validation on structure and the invoice content level, for example that the invoice line amounts match the total amounts given on the invoice. If the route where invoice is going to requires validation, Maventa does this before distributing the invoice and returns an error if the invoice is not valid.

See more information of the validation below.

Against what are invoices validated to

Minimum invoice information requirements

XML schematron validation

  • Invoice structure and content validation
  • Used for Peppol BIS or EN-16391 tagged Finvoice 3.0 / TeApps 3.0
    • If the outgoing format is Peppol BIS (always EN-16931 content) the content is validated with Peppol provided schematron.
    • If the outgoing invoice is Finvoice or TeApps and it is marked as EN-16931 compatible it is validated by the schematron used commonly by the finnish operator network (Verkkolasku Foorumi).
  • If the invoice is routed to Print / eMail / internal delivery, the schematron result is ignored

Bank network validation

  • Bank network specific validations if invoice is sent to netbank (e.g. due date, Finvoice EPIDetails element in B2C invoices)

Note also that in all cases when Maventa converts files, the converted files are made to be structurally correct, i.e. they follow XML schema (XSD) of the target conversion format.

How do I know which validations need to be made?

Maventa does automatically the required validations and returns an error if the invoice is not valid for the route it is sent to.

First validation on minimum invoice information requirements is done before invoice appears on the outgoing invoice listing (UI / API calls). If the invoice doesn’t meet the requirements it will be rejected on the API.

The other validations schematron and bank network will be done if needed once the invoice is routed and prepared for sending. The status of the invoice will indicate whether it has been sent (1) or still in the sending process (0) or it has failed (99).

How can I make sure that the invoice doesn’t fail on validation?

Make sure that the material you are sending is following the specifications of the format you are using. This ensures also that conversion of the XML will work in a good way. Maventa handles conversions between the supported XML formats. However, note that there may be some limitations if the format version you are using is very old, i.e. there can be some elements that cannot be properly converted. We recommend to use the latest versions of the formats to ensure the best compatibility on conversions.

Links to some commonly used format documentation

Finvoice & Teapps phase-in error message

Validation rules require changes time to time. There is an error message which reveals the upcoming changes.

The phase-in error message is due to phase-in feedback having revealed an error in e-invoicing data that must be corrected. If not corrected, the error will cause an invoice to be rejected in the next version of rules. This provides a way for billers and developers to correct the discovered error now, before the launch of the next ruleset.

Can I validate/test my material before sending and how?

There are different validation tools that can be used for testing the material you are sending.

Maventa offers possibility to validate documents over API with the help of AutoValidator tool.

The tool supports also schematron validation of Peppol BIS 3.0, TeApps 3.0 and Finvoice 3.0.