Research date: 2026-09-02. Direct browser research of auditfile.nu using live browser tooling (Kapture MCP). Companion to docs/research-dutch-audit-standards.md (which covered odb.belastingdienst.nl and regulatory sources).
auditfile.nu is a practitioner/community site, not the official regulatory source. It is run by Olaf de Vriend, a Dutch accountant who built PowerBI analysis templates for XAF 3.2 files. The site sells analysis services (€399/file) and distributes free inleesscripts (PowerBI import templates). It is not affiliated with the Belastingdienst, SRA, or any standards body.
The official regulatory source for the XAF standard is:
https://odb.belastingdienst.nl/auditfiles/ (Ondersteuning Digitaal Berichtenverkeer — requires authenticated portal login to download the XSD ZIP)https://odb.belastingdienst.nl/auditfiles/xmlauditfile-financieel-xaf-v-4-0-3/ (login-gated)The historical governance per auditfile.nu's own version history page: Belastingdienst originated the standard, SRA (Harold Kinds) designed v1.0, ABZ designed v3.0. Current governance: "Auditfileplatform" (Belastingdienst + SRA collaboration).
auditfile.nu covers XAF 3.2 only and does not mention XAF 4.0 anywhere on the site.
| Version | Notes | |---|---| | ASCII Auditfile Financieel | CLAIR 1.0, designed by Belastingdienst | | XML Auditfile Financieel 1.0 | CLAIR 2.0, designed by SRA/Harold Kinds | | XML 3.0 | No CLAIR, added subadministraties and openingsbalans (designed by ABZ) | | XML 3.1 | Improved 3.0 with small fixes | | XML 3.2 | Improved 3.1: added option to include RGS codes, history of master data (stamgegevens) |
XAF 3.2 is the last 3.x version. auditfile.nu lists no higher version. The file extension for XML variants is .xaf; ASCII variant is .adf.
The financial auditfile contains:
The auditfile.nu page for XAF financieel displays a real XAF 3.2 sample file screenshot (XAF_Financieel_3_2_Xml.png). The structure visible in that image shows:
Root element and namespace:
<auditfile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.auditfiles.nl/XAF/3.2"
xsi:schemaLocation="http://www.auditfiles.nl/XAF/3.2
C:\XAF\...\XmlAuditfileFinancieel3.2.xsd">
Namespace http://www.auditfiles.nl/XAF/3.2 is confirmed as correct for XAF 3.2. This matches Athena's package-info.java.
<header> (confirmed from image):
<header>
<fiscalYear>...</fiscalYear>
<startDate>1967-08-13</startDate> <!-- ISO date -->
<endDate>1967-08-13</endDate>
<curCode>AED</curCode> <!-- ISO 4217 currency code -->
<dateCreated>1967-08-13</dateCreated>
<softwareDesc>String</softwareDesc>
<softwareVersion>String</softwareVersion>
</header>
<company> (confirmed from image — partial, image truncates at streetAddress):
<company>
<companyIdent>String</companyIdent>
<companyName>String</companyName>
<taxRegistrationCountry>AD</taxRegistrationCountry>
<taxRegIdent>String</taxRegIdent> <!-- KvK number / BTW number -->
<streetAddress>
<streetname>String</streetname>
<number>String</number>
<numberExtension>String</numberExtension>
<property>String</property>
<city>String</city>
...
</streetAddress>
...
Full XAF 3.2 structure beyond what the image shows (from schema knowledge, not directly verified from auditfile.nu image — flagged):
The image was truncated before showing the general ledger and transaction sections. The following structure is based on training-data knowledge of the XAF 3.2 XSD (XmlAuditfileFinancieel3.2.xsd), which is consistent with the auditfile.nu PowerBI inleesscript and the AnalyticsLibrary GitHub project, but not directly verified against the XSD in this session (the XSD requires Belastingdienst portal authentication):
<generalLedger>
<ledgerAccount>
<accID>...</accID>
<accDesc>...</accDesc>
<accTp>...</accTp> <!-- P=profit&loss, B=balance -->
<leadCode>...</leadCode> <!-- RGS reference code (added in 3.2) -->
<opBal>...</opBal> <!-- opening balance (added in 3.0) -->
<clBal>...</clBal> <!-- closing balance (added in 3.0) -->
<transactions>
<linesCount>...</linesCount>
<totalDebit>...</totalDebit>
<totalCredit>...</totalCredit>
<journal>
<jrnID>...</jrnID>
<jrnDesc>...</jrnDesc>
<jrnTp>...</jrnTp> <!-- B=bank, M=memorial, I=inkoop, V=verkoop -->
<transaction>
<nr>...</nr>
<desc>...</desc>
<periodNumber>...</periodNumber>
<trDt>...</trDt> <!-- transaction date -->
<amnt>...</amnt> <!-- total amount -->
<amntTp>...</amntTp> <!-- D=debit, C=credit -->
<trLine>
<nr>...</nr>
<accID>...</accID>
<docRef>...</docRef>
<effDate>...</effDate>
<desc>...</desc>
<amnt>...</amnt>
<amntTp>...</amntTp> <!-- D or C -->
<custSupID>...</custSupID> <!-- links to customerSupplier -->
<invRef>...</invRef>
</trLine>
<!-- multiple trLine elements per transaction (double-entry) -->
</transaction>
</journal>
</transactions>
</ledgerAccount>
</generalLedger>
<customersSuppliers>
<customerSupplier>
<custSupID>...</custSupID>
<custSupName>...</custSupName>
<custSupTp>D</custSupTp> <!-- D=debtor, C=creditor -->
...address fields...
<bic>...</bic>
<iban>...</iban>
</customerSupplier>
</customersSuppliers>
</company>
auditfile.nu explicitly states: "Norway has adopted the Dutch auditfile family and converted both XAF (financieel) and XAA (afrekensystemen) nearly integrally, renaming them to the Norwegian SAF-T." The site notes that if accounting software supports Norwegian SAF-T it can likely produce Dutch-compatible auditfiles. This confirms the earlier research finding that XAF predates and inspired SAF-T (though the causal claim remains secondary-source-only).
Directly relevant to Athena:
| Resource | URL | Price | Format | Relevance |
|---|---|---|---|---|
| Gratis inleesscript XAF 3.2 | https://auditfile.nu/product/xaf-3-2-inleesscript/ | Free (€0) | PowerBI (.pbit) + PDF instruction | HIGH — PowerBI import script for XAF 3.2; shows real-world element name mapping used by practitioners |
| Analyse XAF 3.2 | https://auditfile.nu/product/analyse-xaf-3-2/ | €399 | Service (Auditfile.nu analyses your XAF) | LOW for tooling |
| XAF analyse voor curatoren | https://auditfile.nu/product/financiele-auditfile-xaf-analyse-voor-curatoren/ | €399 | Service | LOW |
| Gratis inleesscript XAA 3.21 | https://auditfile.nu/product/gratis-inleesscript-xaa-3-21/ | Free | PowerBI | Not relevant to XAF |
Critical finding: No XSD schema files are available on auditfile.nu. The site does not host or link to the official XAF 3.2 XSD. For the official XSD, the only confirmed source is odb.belastingdienst.nl/auditfiles/ (login-required).
AnalyticsLibrary GitHub (https://github.com/AnalyticsLibrary/Analytics): listed on auditfile.nu as the open-source project behind the inleesscript. This repo may contain the PowerBI M-query that reads XAF 3.2 and could be inspected to confirm element names used in practice. Olaf de Vriend contributed the XAF 3.2 inleesscript to this project.
No example/reference XAF files are distributed as free downloads on auditfile.nu — only the PowerBI template and the analysis service. The AnalyticsLibrary GitHub may contain sample files.
The parser lives in backend/src/main/java/nl/glorylabs/athena/xaf/. Key facts:
| Component | Current state |
|---|---|
| XafParser.java | JAXB-based unmarshaller. Uses SAX pre-validation for XXE safety. Targets AuditFileDto.class. |
| package-info.java | Declares namespace http://www.auditfiles.nl/XAF/3.2 — correct |
| AuditFileDto.java | Maps <auditfile> → header + generalLedgerAccounts + transactions |
| HeaderDto.java | Maps <header> → companyName, fiscalYear, startDate, endDate, currency |
| GeneralLedgerAccountDto.java | Maps <account> → accountID, accountDescription, accountType, rgsCode (leadCode) |
| TransactionDto.java | Maps <transaction> → transactionID, transactionDate, accountID, description, debitAmount, creditAmount, createdBy, manualEntry |
The test fixture (audit_training_liquide_middelen_02_voorbeeld_auditfile_XAF.xml) uses the same simplified structure the parser targets — a custom simplified format that uses the XAF 3.2 namespace but departs heavily from the XAF 3.2 XSD.
Cross-referencing the parser/DTOs against the real XAF 3.2 structure (confirmed from auditfile.nu image + schema knowledge). Severity: CRITICAL = real files fail to parse, SIGNIFICANT = data loss on real files, MODERATE = missing data fields.
<company> wrapper — real XAF files fail to parseIn real XAF 3.2, the entire general-ledger and transaction data lives inside a <company> element. Athena maps <generalLedgerAccounts> and <transactions> as direct children of <auditfile>. A real XAF 3.2 export from any Dutch accounting package (Exact, Twinfield, AccountView, etc.) will have:
<auditfile xmlns="http://www.auditfiles.nl/XAF/3.2">
<header>...</header>
<company>
<generalLedger>...</generalLedger> <!-- inside company -->
<customersSuppliers>...</customersSuppliers>
</company>
</auditfile>
Athena expects <generalLedgerAccounts> directly under <auditfile> — JAXB will silently return an empty list; no parse error is thrown, but all data is lost. Every real XAF 3.2 file from a Dutch accounting package will parse as empty transactions and empty chart of accounts.
Athena models transactions as a flat list: <transactions> → <transaction> (single-sided, one debit or credit amount per record).
Real XAF 3.2 uses a three-level hierarchy:
<generalLedger>
<ledgerAccount> (per GL account)
<transactions>
<journal> (per journal — bank, memorial, purchase, sales)
<transaction> (a journal entry = balanced double-entry)
<trLine> (individual line: one account, one amount D or C)
<trLine>
...
A single accounting entry (e.g. a customer payment) generates one <transaction> with at minimum two <trLine> elements (debit bank account, credit receivables). Athena's parser will fail to find any transactions in a real file because: (a) transactions are nested inside <company>/<generalLedger>/<ledgerAccount>/... not directly under <auditfile>/<transactions>, and (b) the element names are completely different.
This is the pre-identified gap. It is confirmed as a real structural mismatch, not a minor naming issue.
| Location | Real XAF 3.2 element | Athena element | Match? |
|---|---|---|---|
| Header | <curCode> | <currency> | No |
| Header | <fiscalYear> | <fiscalYear> | Yes |
| Header | <startDate> | <startDate> | Yes |
| Header | <endDate> | <endDate> | Yes |
| Header | <companyName> (in <company>) | <companyName> (in <header>) | Wrong location |
| GL section wrapper | <generalLedger> | <generalLedgerAccounts> | No |
| GL account element | <ledgerAccount> | <account> | No |
| GL account ID | <accID> | <accountID> | No |
| GL account description | <accDesc> | <accountDescription> | No |
| GL account type | <accTp> | <accountType> | No |
| GL account RGS code | <leadCode> | <leadCode> | Yes (correct) |
| Transaction number | <nr> | <transactionID> | No |
| Transaction description | <desc> | <description> | No |
| Transaction date | <trDt> | <transactionDate> | No |
| Transaction line element | <trLine> | (none — flat) | No |
| Line amount | <amnt> | <debitAmount> / <creditAmount> | Structural mismatch |
| Line debit/credit flag | <amntTp> (D/C enum) | separate debit/credit fields | Structural mismatch |
| Line account | <accID> in <trLine> | <accountID> in <transaction> | No |
Athena's element naming is entirely non-standard — it appears to have been designed for the training dataset's simplified structure, not for XAF 3.2 compliance.
Real XAF 3.2 <header> contains fields Athena does not map:
| Real XAF 3.2 field | In Athena HeaderDto? | Notes |
|---|---|---|
| <fiscalYear> | Yes | |
| <startDate> | Yes | |
| <endDate> | Yes | |
| <curCode> | No (mapped as <currency>) | Wrong name |
| <dateCreated> | No | Date the auditfile was created |
| <softwareDesc> | No | Name of the accounting software |
| <softwareVersion> | No | Version of the accounting software |
Additionally, <companyName> is in Athena's HeaderDto but in real XAF 3.2 it belongs inside <company>, not <header>. The real <header> has no company name.
<company> sectionReal XAF 3.2 includes a full company registration block that Athena has no DTO for:
<company>
<companyIdent>...</companyIdent> <!-- internal ID -->
<companyName>...</companyName> <!-- company name (NOT in header) -->
<taxRegistrationCountry>NL</taxRegistrationCountry>
<taxRegIdent>...</taxRegIdent> <!-- KvK/BTW number -->
<streetAddress>
<streetname>...</streetname>
<number>...</number>
<numberExtension>...</numberExtension>
<property>...</property>
<city>...</city>
<postalCode>...</postalCode>
<country>...</country>
</streetAddress>
<phoneNr>...</phoneNr>
<faxNr>...</faxNr>
<eMail>...</eMail>
<bic>...</bic>
<iban>...</iban>
</company>
The taxRegIdent (KvK/BTW number) is particularly relevant for Athena: it uniquely identifies the audited entity and could be used to cross-check the entity against Kamer van Koophandel records. This field is completely absent from Athena's data model.
<customersSuppliers> sectionReal XAF 3.2 includes a debtors and creditors master list:
<customersSuppliers>
<customerSupplier>
<custSupID>...</custSupID>
<custSupName>...</custSupName>
<custSupTp>D</custSupTp> <!-- D=debtor, C=creditor -->
<custSupAddress>...</custSupAddress>
<bic>...</bic>
<iban>...</iban>
<vatNr>...</vatNr>
</customerSupplier>
</customersSuppliers>
This section is referenced by <trLine> elements (via <custSupID>) and enables lapping/kiting detection by linking transactions to specific counterparties. Athena has no DTO for this section, meaning counterparty data in real XAF files is completely ignored. This is directly relevant to Athena's core analysis features (F-002/F-004 lapping detection).
Real XAF 3.2 <ledgerAccount> includes:
<opBal> — opening balance for the period (added in XAF 3.0)<clBal> — closing balance for the period (added in XAF 3.0)Athena's GeneralLedgerAccountDto has no balance fields. This means Athena cannot perform balance-sheet verification (checking that beginning + mutations = ending balance) on real XAF files, which is a standard audit procedure.
Real XAF 3.2 groups transactions by journal:
<jrnID> — journal identifier<jrnDesc> — journal description<jrnTp> — journal type code (B=bank, M=memorial/gedenkpost, I=inkoop/purchase, V=verkoop/sales, K=kas/cash)This information is critical for Athena's F-002 finding (unsupported manual journal entries): memorial journal entries (jrnTp=M) are the primary risk area. Without journal-type data, Athena must rely on the <manualEntry> flag in its simplified fixture format, which is not a standard XAF 3.2 field at all.
Athena's TransactionDto contains fields that do not exist in the XAF 3.2 schema:
<createdBy> — not a standard XAF 3.2 field<manualEntry> — not a standard XAF 3.2 fieldThese were apparently invented for the training dataset's simplified format. In real XAF 3.2, "manual entry" detection must be inferred from jrnTp=M (memorial journal) rather than an explicit flag.
XAF 4.0 became mandatory as of 1 January 2026 (confirmed by odb.belastingdienst.nl and multiple vendor sources). The Belastingdienst states: "XAF 3.2 files are no longer accepted from January 1, 2026." Athena currently only implements a simplified variant of XAF 3.2. XAF 4.0 specifics are addressed in section 6 below.
Correction (2026-09-03, primary-source ODB scrape): the odb.belastingdienst.nl Auditfiles start page carries the news item "Belangrijke update: Uitfasering oude Auditfiles Financiëel XAF per 01-01-2027" (published 22-04-2026), and the ODB's own XAF 3.2+RGS implementation call remains published. The phase-out date for old XAF versions is therefore 1 January 2027, not 1 January 2026 as stated above — Athena's XAF 3.2 ingestion remains usable for exports produced through 2026, and the XAF 4.0 migration deadline is one year later than previously documented. (Source: datadump
belastingdienst/odb/auditfiles-index.txt, fetched 2026-09-02.)
Source: docs/research-dutch-audit-standards.md section 4 + ODB Belastingdienst background page (directly verified). auditfile.nu does not cover XAF 4.0.
| Aspect | Detail |
|---|---|
| Official point release | 4.0.3 (current), 4.0.2 also available |
| Mandatory since | ~~1 January 2026~~ Corrected (2026-09-03): old XAF phase-out per 01-01-2027 (ODB news item 22-04-2026) |
| Download URL | https://odb.belastingdienst.nl/auditfiles/xmlauditfile-financieel-xaf-v-4-0-3/ (login required) |
| Namespace | Different from 3.2 (not yet confirmed — portal login needed to inspect XSD) |
| Field count | Reduced from ~250 fields (3.2) to ~90 fields (4.0) |
| Design rationale | Many 3.2 fields were inconsistently populated in practice; 4.0 focuses on what's reliably available |
| RGS alignment | Explicitly mandatory in 4.0 (optional in 3.2) |
| Governance | Designed with accountants + software vendor sounding board |
The XAF 4.0 XSD was not directly inspectable in this session (Belastingdienst portal requires authentication). A team member with ODB portal access needs to download the XSD ZIP and inspect the actual schema.
What RGS is: The Dutch standard reference chart-of-accounts numbering system, maintained by the accountancy profession (NBA, NOAB, SRA collaboration). It defines standardized GL account codes that map across different accounting packages, enabling cross-company analysis.
RGS in XAF 3.2: Added as <leadCode> on <ledgerAccount> elements in version 3.2. Optional in 3.2 — accounting packages may or may not populate it.
RGS in XAF 4.0: Explicitly aligned and expected.
Athena's current RGS support: GeneralLedgerAccountDto has a rgsCode field mapped to <leadCode> — the element name is correct for XAF 3.2. However, since Athena's entire GL account mapping uses wrong parent element names (<generalLedgerAccounts>/<account> instead of <generalLedger>/<ledgerAccount>), the rgsCode field will never actually be populated from a real XAF 3.2 file despite the DTO having the field.
RGS lead codes relevant to Athena's liquide middelen focus:
BLimBankBetrekBankrek — bank accounts (betaalrekeningen)BLimBankBetrekGrekeni — G-rekening (blocked accounts)BLimBankBetrekKassgel — cashBLimBankBetrekOverLim — other liquid assetsThese RGS codes could enable Athena to automatically identify bank accounts and G-rekeningen in a real XAF file without requiring manual account selection by the user — a significant UX improvement.
Ordered by impact on making Athena work with real Dutch XAF exports.
The entire DTO tree needs to be rebuilt. This is a fundamental architectural change, not a patch:
CompanyDto with all company-level fieldsAuditFileDto children: remove generalLedgerAccounts and transactions; add companyGeneralLedgerDto containing List<LedgerAccountDto>GeneralLedgerAccountDto fields: accID, accDesc, accTp, leadCode, opBal, clBalJournalDto with jrnID, jrnDesc, jrnTp, List<JournalTransactionDto>JournalTransactionDto with nr, desc, periodNumber, trDt, amnt, amntTp, List<TrLineDto>TrLineDto with nr, accID, docRef, effDate, desc, amnt, amntTp, custSupID, invRefCustomerSupplierDto with custSupID, custSupName, custSupTp, address, bic, ibanHeaderDto: remove companyName, rename currency to curCode, add dateCreated, softwareDesc, softwareVersionpackage-info.java to confirm namespace still http://www.auditfiles.nl/XAF/3.2Estimated size: Large (multiple new DTOs, all existing analysis service logic referencing the old flat TransactionDto must be adapted). All downstream services (ReconciliationService, FinancialKpiService, KengetallenService, etc.) that consume TransactionDto must be updated.
Once the DTO is rebuilt, every service that processes transactions (reconciliation, kengetal calculation, KPI service, population analysis) needs to be rewritten to work with the journal > transaction > trLine hierarchy instead of the flat TransactionDto model. This is not just a field rename — the business logic changes because:
amntTp on each trLine, not separate debitAmount/creditAmount fieldsjrnTp=B (bank journal) or by GL account type, not by account ID patternmanualEntry flag with journal-type-based detection (SIGNIFICANT, medium)The manualEntry boolean in TransactionDto is not a real XAF 3.2 field — it was invented for the training fixture. In real files, manual/memorial entries are identified by jrnTp=M (memorial journal). The F-002 finding logic must be rewritten to detect memorial journal entries via journal type, not a non-standard boolean flag.
Immediate blocker: obtain the XAF 4.0 XSD from odb.belastingdienst.nl/auditfiles/ (requires authenticated portal login). Once the XSD is available:
http://www.auditfiles.nl/XAF/4.0 or http://odb.belastingdienst.nl/XAF/4.0 — not confirmed)XAF 4.0 is mandatory since January 2026 — any XAF export from a Dutch accounting package after that date will be 4.0. This means Athena currently cannot process any XAF export from 2026 onwards.
Correction (2026-09-03, primary-source ODB scrape): per the ODB news item of 22-04-2026, old XAF versions are phased out per 01-01-2027, not 01-01-2026. XAF 3.2 exports remain valid through 2026, so the urgency framing above is one year too aggressive — XAF 4.0 support is still required, but the hard deadline is 1 January 2027. (Source: datadump
belastingdienst/odb/auditfiles-index.txt.)
Neither the XAF 3.2 nor 4.0 XSD is available without authentication. A team member must:
odb.belastingdienst.nlhttps://odb.belastingdienst.nl/auditfiles/xmlauditfile-financieel-xaf-v-4-0-3/ (4.0.3) and the 3.2 equivalentXafParser using javax.xml.validation.SchemaFactory (currently the parser only checks well-formedness, not schema conformance)The current test fixture (audit_training_liquide_middelen_02_voorbeeld_auditfile_XAF.xml) is a non-standard simplified format. Once XAF 3.2 parsing is fixed, real-world fixture files are needed:
https://github.com/AnalyticsLibrary/Analytics) may contain sample XAF files — worth inspecting as it is the source behind auditfile.nu's free inleesscriptOnce the parser correctly maps <leadCode> from real XAF files, add an RGS-code-based account classifier to automatically identify bank accounts, G-rekeningen, and cash accounts. This removes the current dependency on manual account selection and makes Athena more reliable across different companies' account numbering schemes.
<customersSuppliers> parsing for counterparty analysis (MODERATE, medium after item 1)Parse the <customersSuppliers> section to build a custSupID → name/type/IBAN lookup. Use this to:
trLine elements to named counterparties in findings| Resource | URL | Type | Notes |
|---|---|---|---|
| auditfile.nu (community site) | https://auditfile.nu/ | Community/practitioner | By Olaf de Vriend. Focused on XAF 3.2 only. PowerBI tools. |
| XAF 3.2 reference image (from site) | https://auditfile.nu/wp-content/uploads/2020/06/XAF_Financieel_3_2_Xml.png | Image | Shows real XAF 3.2 XML structure (header + company fields) |
| Gratis inleesscript XAF 3.2 | https://auditfile.nu/product/xaf-3-2-inleesscript/ | Free download | PowerBI import template — shows practitioner field name usage |
| AnalyticsLibrary GitHub | https://github.com/AnalyticsLibrary/Analytics | Open source | Source of the inleesscript; may contain sample XAF files |
| ODB Belastingdienst (official) | https://odb.belastingdienst.nl/auditfiles/ | Official | Login-required portal for XSD downloads |
| XAF 4.0.3 download (official) | https://odb.belastingdienst.nl/auditfiles/xmlauditfile-financieel-xaf-v-4-0-3/ | Official | Login required |
| XAF 4.0 background (official) | https://odb.belastingdienst.nl/auditfiles/achtergrond-informatie-xaf4-0/ | Official | Readable without login; confirms 250→90 field reduction, RGS alignment |
| Belastingdienst audit control page | https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/aangifte_betalen_en_toezicht/toezicht/handhaving_en_controle/auditfile-verlicht-administratieve-lasten-voor-ondernemers | Official | Confirmed on auditfile.nu "other websites" page |
| Softwarepakketten.nl auditfile info | https://www.softwarepakketten.nl/swpakketten/auditfiles/auditfiles.php | Secondary | Overview of auditfile-capable software packages |
| Norwegian SAF-T note | (from auditfile.nu XAF page) | Confirmed | Norway adopted XAF/XAA as SAF-T; software supporting NO-SAF-T may export NL-compatible files |
XAF 3.2 XSD not directly accessed — the full XSD file (XmlAuditfileFinancieel3.2.xsd) was not fetched. The generalLedger/journal/transaction/trLine structure documented in section 2.3 is based on schema knowledge consistent with the auditfile.nu image and AnalyticsLibrary project but not verified against the primary XSD in this session. Obtain via ODB portal (login required) or inspect AnalyticsLibrary GitHub.
XAF 4.0 XSD not accessed — the 4.0 namespace, element names, and field structure are not directly confirmed (portal login required). The ~90-field count and RGS alignment are confirmed from the ODB background page.
auditfile.nu inleesscript not downloaded — the free XAF 3.2 PowerBI inleesscript (https://auditfile.nu/product/xaf-3-2-inleesscript/) would confirm the real-world element names used by practitioners and could serve as a cross-reference. Downloading it requires accepting the WooCommerce checkout flow (free but requires cart/checkout).
No direct XAF 4.0 sample files found — no sample XAF 4.0 files were located in this session. The AnalyticsLibrary GitHub may have 3.2 samples but likely not 4.0 yet (given the Jan 2026 mandatory date is recent).
Source: Governance-Auditfile-Familie.pdf, Concept-verslag-Plenaire-Auditfileplatform-vergadering-20191004-.pdf, Concept-Verslag-Plenaire-Auditfileplatform-vergadering-2018-06-14.pdf, Verslag-Plenaire-Auditfileplatform-vergadering-20170614.pdf, 2016-06-15-Verslag-Plenaire-Auditfileplatform-vergadering.pdf — all from odb.belastingdienst.nl/auditfiles/verslagen-en-presentaties-auditfiles/, collected 2026-09-04.
The Governance-Auditfile-Familie document defines the full auditfile family at the time of publication:
| Code | Full name | Domain | |---|---|---| | XAF | XML Auditfile Financieel | General ledger / financial accounting | | XAA | XML Auditfile Afrekensystemen | POS / cash register / afrekensystemen | | XAS | XML Auditfile Salaris | Payroll / salarissystemen | | XAR | XML Auditfile Ritregistratiesystemen | Trip registration / mileage systems | | XAB | XML Auditfile Computerkassa | (also covers computer cash register; relationship to XAA clarified in domain group) | | XAL | XML Auditfile Logistiek | Logistics / voorraadsystemen | | XAC | XML Auditfile Containerterminal | Container terminal systems |
By 2019 the Auditfileplatform had grown to 8 distinct auditfile types (2019 Plenaire).
Per the Governance document and confirmed by the 2016–2019 plenary minutes:
The 2019 Plenaire confirmed that the open-source AnalyticsLibrary REST Data Analytics project was actively developed and publicly available (described as "beschikbaar gesteld" — made available). This strengthens the references to github.com/AnalyticsLibrary/Analytics cited elsewhere in Athena's docs (DA-042, DA-050): the library is an officially Auditfileplatform-recognised open-source tool, not a third-party community project.
Reacties