A corrected invoice does not reference the preceding invoice
When `Invoice type code` (BT-3) is 384 (corrected invoice), the `PRECEDING INVOICE REFERENCE` group (BG-3) should be present at least once.
Only the issuer holds this value: Factlint reports it and never fabricates it. Test your invoice to find out whether it is affected.
The message your validator prints
Copied verbatim from the sealed artefact: this is the exact sentence the check prints when this rule fails.
cii[BR-DE-26] Wenn im Element Invoice type code (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.
ubl[BR-DE-26] Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.
Quoted from schematron-xrechnung 3.0.2, licensed under Apache-2.0.
Common searches around this code
These phrases mirror what an integrator searches for: code, syntax, rule, business field and correction.
Test your file with this error in mind
Upload the invoice involved: the report will say whether this code appears, where it appears in the document, and whether Factlint can only report it or also fix it.
To automate this check in an ERP flow, call the validation API and link every returned code to its public page.
Why this error happens
A corrected invoice that does not say what it corrects forces the recipient to find the original by hand, or to refuse it. That link is also what makes the two entries reconcilable in the accounts.
How to fix it
Reference the original invoice — its number, and its date when you have it. Factlint does not guess it: nothing in the document points to the invoice being corrected.
XML correction example
<ram:TypeCode>384</ram:TypeCode> <!-- ram:InvoiceReferencedDocument absent -->
<ram:InvoiceReferencedDocument><ram:IssuerAssignedID>FA-2026-0041</ram:IssuerAssignedID>