{"id":2176,"date":"2025-10-24T07:54:22","date_gmt":"2025-10-24T05:54:22","guid":{"rendered":"https:\/\/valitool.org\/?p=2176"},"modified":"2025-10-24T07:59:16","modified_gmt":"2025-10-24T05:59:16","slug":"bmf-e-invoicing-format-business-rule-content-errors","status":"publish","type":"post","link":"https:\/\/valitool.org\/en\/bmf-e-invoicing-format-business-rule-content-errors\/","title":{"rendered":"BMF guidance on e-invoicing: what format errors, business rule errors and content errors really mean"},"content":{"rendered":"

On 15 October 2025, Germany\u2019s Federal Ministry of Finance (BMF) published guidance relevant to every business that receives or sends electronic invoices.
For the first time, it clearly distinguishes between format errors<\/strong>, business rule errors<\/strong> and content errors<\/strong>, and explains what each means for the validity of an invoice<\/strong>.<\/p>\n

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

This article summarises the BMF guidance in plain language and uses examples to explain what to look out for.<\/p>\n

1. Checking an e-invoice in several stages<\/h2>\n

The BMF distinguishes three levels of checking:<\/p>\n

    \n
  1. Format validation<\/strong> \u2014 is the file technically well structured and does it comply with the business rules of European standard EN 16931?<\/li>\n
  2. Content checks for statutory correctness<\/strong> \u2014 are the mandatory details required by the German VAT Act (\u00a7\u00a7 14 and 14a UStG) correct?<\/li>\n
  3. Other content checks<\/strong> \u2014 does the invoice comply with the selected format, such as XRechnung or ZUGFeRD, and is it arithmetically and factually correct<\/strong>?
    Does it actually charge for the services provided or goods delivered, and has the correct tax treatment<\/strong> been applied?<\/li>\n\n<\/ol>\n

    An e-invoice is completely free of errors<\/strong> only when it meets all three levels<\/strong>.<\/p>\n

    2. Format errors \u2014 the basic technical case<\/h2>\n

    A format error<\/strong> occurs when a file does not meet EN 16931 requirements<\/strong> or is not machine-readable<\/strong>.
    In this case it is not<\/strong> an e-invoice, but an \u201cother invoice in a different electronic format\u201d<\/strong>.<\/p>\n

    Example: missing currency<\/h3>\n

    Example:<\/strong> EN 16931 requires the currency to be specified. If it is missing from the XML file, this is a format error<\/strong>, even if UBL or CII does not generate a technical error message.<\/p>\n

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

    Neither CrossIndustryInvoice nor UBL technically requires the currency field:<\/p>\n

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

    This example shows that European standard EN 16931<\/strong> clearly requires the invoice currency (BT-5)<\/strong>. Cardinality 1..1<\/strong> means the field must appear exactly once<\/strong>.
    In the underlying CII<\/strong> and UBL<\/strong> syntaxes, however, the field has cardinality 0..1<\/strong> and is therefore technically optional<\/strong>.
    An XML file can therefore be formally valid without a currency<\/strong>, while failing to meet the business requirements<\/strong> of EN 16931.
    In practice, this results in a format error<\/strong> because the invoice is not fully compliant with the standard, even if its technical structure is correct.<\/p>\n

    \n\"XML\n
    Example: XML file with no currency specified<\/figcaption>\n\n<\/figure>\n

    The result: <\/strong>this is not an e-invoice but an other electronic invoice<\/strong>, which may only be accepted with the recipient\u2019s consent.<\/p>\n

    Consequence:<\/strong> during the transitional period, before mandatory sending applies, the recipient may<\/strong> accept such an invoice but does not have to<\/strong>.
    Once the issuer is required to issue an e-invoice, the recipient must reject<\/strong> invoices with format errors.<\/p>\n

    3. Business rule errors \u2014 linking technology and content<\/h2>\n

    European standard EN 16931<\/strong> and formats based on it, including XRechnung<\/strong> and ZUGFeRD<\/strong>, define business rules<\/strong>.
    These rules describe which information an e-invoice must contain<\/strong> and how the information is logically related<\/strong>.<\/p>\n

    For example:
    If an invoice states a tax rate<\/strong>, it must also state the corresponding tax amount<\/strong>.
    Similarly, if a discount amount is specified, its reason must not be missing.<\/p>\n

    Many of these business rules can be checked technically<\/strong>. This is precisely what validation tools<\/a> do: automatically check these relationships.
    Other rules, such as economic plausibility or tax interpretation, must be checked manually or with the help of an ERP system<\/strong>.<\/p>\n

    Business rules support both levels<\/h3>\n

    Business rules play a part in two phases of checking:<\/p>\n

      \n
    1. During format validation<\/strong>
      They ensure the file is technically correct<\/strong> and compliant with EN 16931<\/strong>.
      An error found here is a format error<\/strong>.
      \u2192 Example: a mandatory detail required by the standard is missing or in the wrong place.<\/li>\n
    2. During content checks<\/strong>
      They help establish whether the invoice is consistent and complete<\/strong>: whether its details fit together logically and meet VAT requirements<\/strong>.
      \u2192 Example: the seller\u2019s address is incomplete. EN 16931 itself requires only the name and country.<\/li>\n\n<\/ol>\n

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

      Technical and content validation build on each other step by step:<\/p>\n

        \n
      1. Technical validation<\/strong> \u2014 CII\/UBL structure (XSD)<\/li>\n
      2. EN 16931 business rule validation<\/strong> \u2014 European core rules<\/li>\n
      3. CIUS \/ extension business rule validation<\/strong> \u2014 national or industry-specific additions, such as XRechnung and ZUGFeRD<\/li>\n
      4. Content checks<\/strong> \u2014 ERP system or manual<\/li>\n\n<\/ol>\n
        \n\"Diagram\n
        From format errors to content errors: the four e-invoice validation stages under the BMF\u2019s 2025 guidance.<\/strong>
        Technical CII\/UBL validation under EN 16931 proceeds through business rule checks before the final content review.<\/figcaption>\n\n<\/figure>\n

        4. Content errors \u2014 factual, arithmetic or tax errors<\/strong><\/h2>\n

        Content errors concern the actual substance of the invoice<\/strong>.
        They arise when an invoice is incorrect in its tax treatment, arithmetic or facts<\/strong>, for example through incorrect amounts, tax rates or service descriptions.<\/p>\n

        However, not every content error automatically makes an invoice non-compliant<\/strong> within the meaning of the German VAT Act.<\/p>\n

        \n

        An invoice is non-compliant under \u00a7 14 UStG<\/strong> only when
        the statutory mandatory details under \u00a7\u00a7 14 and 14a UStG<\/strong> are incomplete or incorrect<\/strong>.<\/p><\/blockquote>\n\n<\/figure>\n

        Content that can be checked technically or substantively<\/strong><\/h3>\n
          \n
        1. Content that can be checked technically<\/strong>
          Some content errors can be identified using business rules<\/strong> checked automatically by validation tools<\/a>.
          Examples include: