D406 MasterFiles: resolve a missing reference

Follow the reference into the supplied file

A journal line can carry an account identifier with a valid lexical form while referring to no account in its MasterFiles. A schema may validate the string without proving that the exporter included the corresponding master record. The independent D406-MASTER-REF check follows account, customer, supplier and product keys within the supplied file. It compares exact keys after trimming XML whitespace and does not contact an external registry.

In the fictional example, the first journal line uses account 999999 while the local account list contains 411100 and 701000. The diagnostic points to the line that uses the missing key, rather than to an unrelated occurrence in the header. Its location is /d:AuditFile[1]/d:GeneralLedgerEntries[1]/d:Journal[1]/d:Transaction[1]/d:TransactionLine[1]/d:AccountID[1], line 28 of this fixture.

Choose the correct repair in the exporter

Start by checking whether the intended account was omitted from the master-data selection. Export filters sometimes select only accounts with closing balances and miss an account used earlier in the period. Another cause is inconsistent normalisation: one exporter branch may include leading zeros or a subaccount suffix while another removes them. The tool does not guess that two different strings identify the same account.

Do not automatically replace every unknown reference with the first known key. Confirm the intended posting in the source accounting system, then correct either the reference or the omitted master record. The displayed before/after fragment demonstrates only this fictional mismatch. It is not advice to recode a real posting to account 411100.

Keep segments and tax pairs in view

When the header declares multiple segments, a missing key becomes a review warning: the relevant master may belong to another segment. This lite tool does not merge segments or establish their completeness. Validate the complete reporting set with the appropriate process before deciding that a reference is actually wrong. A partial file must not receive a complete green result simply because the known local checks passed.

Tax references use the TaxType and TaxCode pair together. Reusing a code under a different tax type does not satisfy D406-TAX-REF. Membership in the supplied TaxTable proves only a local relationship. It does not prove that the code, rate, exemption or effective date is legally correct for the reporting period; no official XLSX code list is bundled.

Read the report without overstating it

The report separates local business failures from plausibility warnings, supplied-schema results and checks that were not performed. It records the independent rule version, the schema SHA256 when supplied, provenance and the scope for each file. Reports are generated on your device. Sensitive XML, accounting values and identifiers are not sent to analytics.

Use the ANAF dictionary and the current DUK tooling to review official requirements after repairing your exporter. The official consistency publications dated 9 March 2023 and 19 August 2024 remain a separate unchecked layer here. This reference check cannot confirm a complete tax audit, an account’s economic meaning or DUK/SPV acceptance.

Primary sources and scope

Use the ANAF D406 download page for the currently published XSD and Soft J. The official SAF-T project page lists the dictionary, DUK and separate consistency publications. These links identify the primary source; the explanations and example above were written independently.