{"id":1680,"date":"2025-10-24T07:54:22","date_gmt":"2025-10-24T05:54:22","guid":{"rendered":"https:\/\/validool.org\/2025\/10\/bmf-letter-on-e-invoicing-what-format-errors-business-rule-errors-and-content-errors-really-mean\/"},"modified":"2025-10-24T08:31:50","modified_gmt":"2025-10-24T06:31:50","slug":"bmf-letter-on-e-invoicing-what-format-errors-business-rule-errors-and-content-errors-really-mean","status":"publish","type":"post","link":"https:\/\/validool.org\/en\/2025\/10\/bmf-letter-on-e-invoicing-what-format-errors-business-rule-errors-and-content-errors-really-mean\/","title":{"rendered":"BMF letter on e-invoicing: What format errors, business rule errors and content errors really mean"},"content":{"rendered":"\n

On October 15, 2025, the Federal Ministry of Finance (BMF) published a letter (BMF letter) that is important for all companies that receive or send electronic invoices.For the first time, it clearly distinguishes between format errors<\/strong>, business rule errors<\/strong> and content errors<\/strong> – and what each means for the validity of an invoice<\/strong>.<\/p>\n\n

Many companies are now asking themselves:When must<\/strong> an e-invoice be rejected?When can<\/strong> it be accepted?And what happens if the file is technically valid but the content is incorrect?<\/p>\n\n

This article summarizes the BMF letter in easy-to-understand language and uses examples to show what you need to pay attention to in future.<\/p>\n\n

1. Multi-stage verification of an e-invoice<\/h2>\n\n

The BMF distinguishes between three stages of the audit:<\/p>\n\n

    \n
  1. Format check<\/strong> – is the file technically correct and does it comply with the business rules of the European standard EN 16931?<\/li>\n\n\n\n
  2. Content check with regard to correctness<\/strong> – is the mandatory information according to the VAT Act (Sections 14 and 14a UStG) correct? <\/li>\n\n\n\n
  3. Other content check<\/strong> – does the invoice correspond to the selected format (e.g. XRechnung, ZUGFeRD) and is it mathematically and factually correct<\/strong>?Were the services rendered or goods delivered actually invoiced – and was the correct tax case<\/strong> applied?<\/li>\n<\/ol>\n\n

    Only if all three levels<\/strong> are fulfilled is it a completely error-free e-bill<\/strong>.<\/p>\n\n

    2. Format error – the basic technical case<\/h2>\n\n

    A format error<\/strong> exists if the file does not meet the requirements of EN 16931<\/strong> or is not machine-readable<\/strong>.In this case, it is not<\/strong> an e-invoice, but an “other invoice in another electronic format”.<\/strong><\/p>\n\n

    Example: Missing currency<\/h3>\n\n

    Example:<\/strong> In EN 16931, the currency must be specified. If it is missing in the XML file, there is a format error<\/strong> – even if UBL or CII do not technically issue an error message. <\/p>\n\n

    \n

    BR-5: An invoice must have a code for the invoice currency (BT-5).<\/p>\nEN16931-1:2017<\/cite><\/blockquote>\n\n

    Neither CrossIndustryInvoice nor UBL technically require the currency to be specified:<\/p>\n\n

    \"Table
    BT-5 “Invoice currency” – mandatory in EN 16931 (1..1), technically optional in CII and UBL (0..1).<\/figcaption><\/figure>\n\n

    The example shows that the European standard EN 16931<\/strong> stipulates a clear obligation to specify the invoice currency (BT-5)<\/strong> – cardinality 1..1<\/strong> means that this field must<\/strong> be present exactly once<\/strong>.In the underlying syntaxes CII<\/strong> and UBL<\/strong>, however, the field is only defined as 0..1<\/strong> and is therefore technically optional<\/strong>.This means that an XML file can also be formally valid without a currency specification<\/strong>, but does not meet the technical requirements<\/strong> of EN 16931.In practice, this leads to a format error<\/strong>, as the invoice is not fully compliant with the standard – even if it is structured correctly from a technical perspective.<\/p>\n\n

    \"XML
    Example: XML file with missing currency specification<\/figcaption><\/figure>\n\n

    The consequence: <\/strong>it is not an e-invoice, but another electronic invoice<\/strong> that may only be accepted with the recipient’s consent.<\/p>\n\n

    Consequence:<\/strong> During the transitional period (until the obligation to send), the recipient may<\/strong> accept such an invoice, but is not obliged to do so<\/strong>.As soon as the invoice sender is obliged to issue an e-invoice, the recipient must<\/strong> reject<\/strong> format error invoices.<\/p>\n\n

    3. business rule errors – the link between technology and content<\/h2>\n\n

    So-called business rules<\/strong> are defined in the European standard EN 16931<\/strong> and in the formats based on it, such as XRechnung<\/strong> and ZUGFeRD<\/strong>.These rules describe which information must be present in an e-invoice<\/strong> and how they are logically interrelated<\/strong>.<\/p>\n\n

    An example:If an invoice contains a tax rate<\/strong>, the corresponding tax amount<\/strong> must also be specified.Or: If a discount value is specified, the reason for the discount must not be missing.<\/p>\n\n

    A large proportion of these business rules can be checked technically<\/strong> – that’s exactly what validation tools <\/a>do: automatically check the correlations.Other rules – such as those relating to economic plausibility or tax interpretation – must be checked manually or with the support of an ERP system<\/strong>.<\/p>\n\n

    The business rules support both levels<\/h3>\n\n

    Business rules play a role in two phases of the audit:<\/p>\n\n

      \n
    1. During the format check<\/strong>You ensure that the file is technically correct<\/strong> and compliant with EN 16931<\/strong>.If an error is detected here, this is referred to as a format error<\/strong>.\u2192 Example: A mandatory entry in the standard is missing or in the wrong place.<\/li>\n\n\n\n
    2. The content check<\/strong>helps you to identify whether the content of<\/strong> the invoice is consistent and complete<\/strong> – i.e. whether the information matches logically and meets the VAT requirements<\/strong>.\u2192 Example: The seller’s address is not complete. EN 16931 itself only requires the name and country to be stated. <\/li>\n<\/ol>\n\n

      The four test stages at a glance<\/strong><\/h3>\n\n

      The technical and content validation builds on each other step by step:<\/p>\n\n

        \n
      1. Technical inspection<\/strong> – CII\/UBL structure (XSD)<\/li>\n\n\n\n
      2. Business rule check EN 16931<\/strong> – European basic rules<\/li>\n\n\n\n
      3. Business rule check CIUS \/ extension<\/strong> – national or industry-specific additions (e.g. XRechnung, ZUGFeRD)<\/li>\n\n\n\n
      4. Content check<\/strong> – ERP system or manual<\/li>\n<\/ol>\n\n
        \"Diagram
        From format error to content error – the four verification stages of an e-invoice in accordance with the BMF letter E-Invoice 2025.<\/strong>The technical validation in accordance with CII\/UBL in accordance with EN 16931 is carried out step by step using business rule checks before the final content check takes place.<\/figcaption><\/figure>\n\n

        4. Content errors – factual, arithmetical or vat related errors<\/strong><\/h2>\n\n

        Content errors relate to the actual content of the invoice<\/strong>.They are always present if the invoice is incorrect in terms of tax, calculation or content<\/strong> – for example, if it contains incorrect amounts, tax rates or service details.<\/p>\n\n

        However, not every content error automatically means that an invoice is not proper<\/strong> within the meaning of the VAT Act.<\/p>\n\n

        An improper invoice in accordance with Section 14 UStG<\/strong> only existsif the legally prescribed mandatory information in accordance with Sections 14 and 14a UStG<\/strong> is incomplete or incorrect<\/strong>.<\/p><\/blockquote><\/figure>\n\n

        Technically and professionally verifiable content<\/strong><\/h3>\n\n
          \n
        1. Technically verifiable content<\/strong>
          Some of the content errors can be detected via business rules<\/strong> that are automatically checked by validation tools<\/a>.
          These include, for example:\n