D406 NumberOfEntries: transactions versus journal lines

Count the right accounting object

An exporter can produce a perfectly readable integer and still count the wrong object. In GeneralLedgerEntries, NumberOfEntries describes Transaction records across the journals in that file. A transaction can contain several TransactionLine records. Treating every debit or credit line as a separate transaction therefore inflates the declared count. The distinction also matters when an ERP groups several source rows into one accounting voucher.

Our fictional file contains one Transaction with two lines: one debit and one credit. Its ledger declaration is one, not two. The independent preflight displays both statistics so the difference remains visible. In SalesInvoices or PurchaseInvoices, the same element name instead counts Invoice records in that container. Adding all occurrences of NumberOfEntries together would confuse these separate contexts.

Find the stale declaration

The broken example declares two ledger entries. D406-COUNT points to /d:AuditFile[1]/d:GeneralLedgerEntries[1]/d:NumberOfEntries[1], line 23 in the supplied fixture. The d prefix in the report denotes the ANAF namespace; your XML can use a different prefix. The check uses the namespace and parent context rather than matching unqualified tag text anywhere in the document.

Compare the declared count against the records remaining after export filters, cancellations and segment splits. If the exporter calculates the header before dropping a voucher, the count can be stale even though every remaining transaction is correct. Repair the exporter’s grouping or finalisation order. Changing a genuine accounting transaction just to match a control field hides the original defect.

Reconcile amounts separately

Matching the count says nothing about debit or credit totals. The separate D406-TOTAL check sums recognized DebitAmount/Amount and CreditAmount/Amount values, using fixed point arithmetic. CurrencyAmount is not substituted for Amount: a foreign-currency amount belongs to a different representation. Present control totals are checked; absent optional declarations are not invented.

A transaction whose debit and credit differ receives a plausibility warning because partial exports and segmentation need context. Cross-segment completeness remains outside this tool. The report contains no accounting amounts or file names, but includes the source path, line, rule version and remaining scope. Export it locally for the correction round.

Confirm the next layer

The demo passes the independently written facts after correcting the count. It does not establish validity against the official XSD. Supply an authorised self-contained schema with provenance if you need that separate layer. The official artifact inspected on 6 November 2026 has schema version 2.4.9; its embedded descriptive version differs, so the root version is recorded explicitly.

Use the current official Soft J / DUK after these local checks, with the appropriate reporting year and month. The complete ANAF consistency publications are not executed here. A passed count is a narrow technical result, not a fiscal audit or a guarantee that SPV will accept a submission.

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.