ViDA Tax Data Document — Version 1.1.0. Ready for use in the ViDA Pilot.

Version 1.1.0

Maintained by Peppol ViDA Pilot Team

Applies to

ViDA Tax Data Document

Release Date

TBD

Status

Review

What’s New in This Release

This is version 1.1.0 of the ViDA Tax Data Document specification. It introduces five changes, all arising from pilot implementation experience:

  • A new mandatory field, the Invoice Transmission UUID (TDT-018), identifying the specific network exchange of the reported invoice.

  • The Invoice UUID (TDT-017) is now validated and its calculation is documented. It must be a version 5 UUID, and the specification now defines exactly how it is derived from the invoice.

  • Time zone information is now genuinely required on the Tax Data Document issue time (TDT-005). The previous rule accepted times without it.

  • Buyer-side reporting now requires VAT amounts. When the reporter role (TDT-012) is C3, the VAT totals and VAT breakdown details must be present.

  • A set of validation rules that never executed has been corrected. Rule contexts carried over from Peppol BIS Billing 3.0 did not match the Tax Data Document structure, so the VAT breakdown rules for every VAT category, currency consistency, and several national rules were silently skipped. They now evaluate as specified.

Three of these changes tighten validation, so Tax Data Documents that passed against version 1.0.0 may need to be regenerated. The corrected rules in particular enforce requirements that were never previously checked. See Upgrading from version 1.0.0-HotFix.

Overview

Version 1.1.0 is the first functional update since 1.0.0-HotFix. It sharpens how a reported invoice is identified, corrects a defect in time validation, closes a gap in what buyer-side reporting must contain, and repairs a group of validation rules that were never executing.

The Semantic Model, Syntax Binding, XML Schema, Schematron rules, documentation and sample documents have all been updated together.

Changes

Identifying the invoice and its transmission

A Tax Data Document refers to an invoice that was exchanged between two trading partners. Version 1.0.0 carried one reference for this, the Invoice UUID (TDT-017), which identifies the invoice as a business document. It had no way to indicate which exchange of that invoice the report relates to — a gap where the same invoice is sent more than once.

Version 1.1.0 adds a second, complementary reference.

New field: Invoice Transmission UUID (TDT-018)

  • Carried as pxs:TransmissionUUID inside the Report Details (TDG-01), before the Reported Document. It sits alongside the reported document rather than inside it, because it describes the exchange of the invoice rather than the invoice content.

  • Mandatory (cardinality 1..1). This is a breaking change relative to version 1.0.0 and is the principal upgrade action for service providers.

  • It identifies one transmission of the invoice across the network, captured by the sender-side (C2) and receiver-side (C3) service provider at the point the Tax Data Document is created.

  • It allows a Tax Authority — specifically its C5 — to distinguish repeated exchanges of the same invoice and to link the related network transactions on both the C2 and C3 side.

Invoice UUID (TDT-017): validated and documented

The Invoice UUID has always been intended as a version 5 UUID calculated from the invoice itself, so that both trading partners' service providers arrive at the same value independently. Neither property was stated in the specification, and neither was validated.

  • The specification now contains an Invoice UUID calculation section under Technical details, defining the fixed namespace, the input fields, how the values are prepared (leading and trailing whitespace removed, nothing else altered), how they are joined into the hashed name (a single space character between values), and test vectors implementations can check themselves against.

  • The calculation is now based on the Seller VAT identifier (BT-31) together with the invoice type code (BT-03), invoice number (BT-01) and issue date (BT-02). It previously used the Seller identifier and its scheme (BT-29/BT-29-1), which are optional in the source invoice and therefore not always available.

  • A new rule verifies that the value carried in a Tax Data Document is a well-formed version 5 UUID.

Because the derivation inputs changed, Invoice UUIDs calculated under earlier drafts will differ from those calculated under version 1.1.0.

Time zone on the issue time

The Tax Data Document issue time (TDT-005) is required to carry time zone information — either Z or a ±hh:mm offset — so that the moment of reporting is unambiguous across borders.

The rule that enforced this contained a defect: the time zone portion of its test expression was marked optional, so a time without any offset passed validation. The expression has been corrected, and the rule now does what it was always intended to do.

Tax Data Documents produced against the defective rule may carry issue times without an offset. These will now fail validation and must be corrected.

Buyer-side reporting: VAT information

The Tax Data Document supports reporting by both the seller side and the buyer side, and these have different reporting obligations. Version 1.0.0 made several VAT fields optional so that both cases could be expressed at all.

Version 1.1.0 restores the requirement where it applies. When the reporter role (TDT-012) is C3:

  • The invoice total VAT amount (BT-110) must be present.

  • The invoice total amount with VAT (BT-112) must be present.

  • Each VAT breakdown (BG-23) must carry the VAT category tax amount (BT-117), VAT category code (BT-118) and VAT category rate (BT-119).

  • Where the invoice uses a separate VAT accounting currency (BT-006), the invoice total VAT amount in that currency (BT-111) must also be present.

Payment instructions (BG-16) remain optional for both roles, so that internal company exchanges — such as own goods movements and the corresponding intra-Community acquisitions — can continue to be reported without payment details.

Validation artefacts

Tax Data Document Schematron

Table 1. New rules
Rule Requirement

ibr-tdd-87

The Invoice UUID (TDT-017) must be a valid version 5 UUID.

ibr-tdd-88

The Invoice Transmission UUID (TDT-018) must be present.

ibr-tdd-89

The Invoice Transmission UUID (TDT-018) must be a valid UUID (any version from 1 to 8).

ibr-tdd-90

Where the reporter role is C3, the invoice total VAT amount (BT-110) must be present.

ibr-tdd-91

Where the reporter role is C3, the invoice total amount with VAT (BT-112) must be present.

ibr-tdd-92

Where the reporter role is C3, each VAT breakdown must carry BT-117, BT-118 and BT-119.

ibr-tdd-93

Where the reporter role is C3 and a VAT accounting currency is used, the invoice total VAT amount in that currency (BT-111) must be present.
Table 2. Changed rules
Rule Change

ibr-tdd-05

Corrected so that time zone information on the issue time is genuinely required.

EN 16931 and Peppol Schematron: corrected rule contexts

A set of validation rules inherited from Peppol BIS Billing 3.0 were never executing against Tax Data Documents. Their rule contexts were written for an XML structure whose document element is the invoice itself. In a Tax Data Document the document element is pxs:TaxData, and the invoice-equivalent level sits two steps below it, at TaxData/ReportedTransaction/ReportedDocument. Contexts anchored at the document root therefore selected nothing, and the rules were silently skipped — no error was raised and validation simply passed.

This release corrects those contexts. No rule requirement has been changed: each rule now evaluates the condition it was always specified to enforce.

Table 3. Corrected rules — CEN-EN16931-UBL.sch
Rule Change

BR-AE-08, BR-AE-09, BR-AE-10

VAT breakdown rules for category AE (Reverse charge) now evaluate.

BR-E-08, BR-E-09, BR-E-10

VAT breakdown rules for category E (Exempt from VAT) now evaluate.

BR-G-08, BR-G-09, BR-G-10

VAT breakdown rules for category G (Export outside the EU) now evaluate.

BR-IC-08, BR-IC-09, BR-IC-10

VAT breakdown rules for category K (Intra-community supply) now evaluate.

BR-AF-08, BR-AF-09, BR-AF-10

VAT breakdown rules for category L (IGIC) now evaluate.

BR-AG-08, BR-AG-09, BR-AG-10

VAT breakdown rules for category M (IPSI) now evaluate.

BR-O-08, BR-O-09, BR-O-10

VAT breakdown rules for category O (Not subject to VAT) now evaluate.

BR-S-08, BR-S-09, BR-S-10

VAT breakdown rules for category S (Standard rated) now evaluate.

BR-Z-08, BR-Z-09, BR-Z-10

VAT breakdown rules for category Z (Zero rated) now evaluate.

UBL-CR-674

Corrected to test cbc:PrimaryAccountNumberID. It previously named cbc:PrimaryAccountNumber, an element that does not exist in UBL, so the constraint never applied.

For each VAT category the three rules cover, respectively: the reconciliation of the VAT category taxable amount (BT-116) against line and document level amounts; the calculation of the VAT category tax amount (BT-117); and the presence or absence of the VAT exemption reason (BT-120/BT-121) required for that category.

Table 4. Corrected rules — PEPPOL-EN16931-UBL.sch
Rule Change

PEPPOL-EN16931-R051

Currency consistency now evaluates. Every branch of the rule’s context had been anchored at the document root, so no amount element was checked. The rule verifies that each @currencyID matches the document currency code (BT-5).

DE-R-001, DE-R-016, DE-R-017, DE-R-026, DE-R-031

Document level German national rules now evaluate. Their shared rule context contained a duplicated ReportedDocument step and could not match.

NL-R-007

Location path in the rule’s test made relative to the rule context, consistent with the other expressions in the same test.
Location paths made relative

Assertions across CEN-EN16931-UBL.sch and PEPPOL-EN16931-UBL.sch used the // shortcut, which searches from the document root rather than from the Reported Document being validated. Ninety-nine assertions have been rewritten to locate nodes relative to their own rule context. Results are unchanged for a Tax Data Document carrying a single Reported Document, which is the case for every document this specification defines; the change removes a dependency on that assumption.

Effect on existing documents

Tax Data Documents that were previously accepted may now be rejected, because the corrected rules enforce requirements that were never checked. The VAT breakdown rules are the most likely source: a breakdown using categories AE, E, G, K or O must carry a VAT exemption reason or reason code, a breakdown using S, Z, L or M must not, and the taxable and tax amounts must reconcile with the line and document level amounts. Currency consistency (PEPPOL-EN16931-R051) is likewise enforced for the first time. Implementers are advised to re-run existing test data against the version 1.1.0 artefacts.

All sample documents published with this release validate cleanly against the corrected rules.

Unchanged in this release

Validation rule BR-IC-12, which requires the Deliver to country code (BT-80) where the VAT category is "Intra-community supply", remains disabled as it was in version 1.0.0-HotFix. The Tax Data Document syntax still does not carry delivery location information, and no change is made to that position here.

Data model and syntax

  • Semantic Model: adds TDT-018 (Invoice Transmission UUID, 1..1) under Report Details (TDG-01); documents the derivation of TDT-017; records the conditional requirement on BT-110, BT-111, BT-112, BT-117, BT-118 and BT-119 for C3 reporting.

  • Syntax Binding: binds pxs:TransmissionUUID in the Report Details, preceding pxs:ReportedDocument.

  • XML Schema: adds the TransmissionUUID element to ReportedTransactionType.

Documentation

  • New Invoice UUID calculation section under Technical details, covering the method, the fixed namespace, the field-by-field construction of the hashed name, a worked example, test vectors, and the handling of invoices with no Seller VAT identifier.

Sample documents

All Billing and Self-Billing samples have been updated:

  • Invoice UUIDs are recalculated using the documented method, so each sample can be reproduced from its own invoice data.

  • The mandatory Invoice Transmission UUID is present in every reported transaction.

The VAT category O samples are the exception: their seller carries no VAT identifier, so no Invoice UUID can be derived for them. They retain placeholder identifiers and are published for structural reference only.

Seven samples are added, covering VAT categories, national rules and buyer-side reporting cases that previously had no example:

Sample Covers

vat-category-AE.xml

VAT category AE (Reverse charge). Spanish seller, Danish buyer, both VAT identifiers present.

vat-category-G.xml

VAT category G (Export outside the EU). Spanish seller, Norwegian buyer with no EU VAT identifier.

vat-category-K.xml

VAT category K (Intra-community supply). Spanish seller, German buyer, with an actual delivery date.

vat-category-L.xml

VAT category L (IGIC) at a 7% rate.

vat-category-M.xml

VAT category M (IPSI) at a 10% rate.

DE-domestic-example.xml

A domestic German invoice, German seller and buyer, exercising the document level German national rules.

C3-accounting-currency-example.xml

Buyer-side (C3) reporting of a domestic Swedish invoice issued in EUR with VAT accounted in SEK. Carries the VAT accounting currency code (BT-006) and the invoice total VAT amount in that currency (BT-111).

Categories L and M are rated regimes rather than exempt ones, so their samples carry non-zero VAT rates and exercise the VAT category tax amount calculation.

C3-accounting-currency-example.xml is the only sample combining the C3 reporter role with a VAT accounting currency, and is what exercises ibr-tdd-93. Its Invoice Transmission UUID is a version 4 UUID, showing that TDT-018 is taken from the transmission and is not derived from the invoice as TDT-017 is.

Together with the existing samples, every rule corrected in this release is now exercised by at least one published example.

Upgrading from version 1.0.0-HotFix

  1. Populate the Invoice Transmission UUID. Every Tax Data Document must now carry it. Service providers on both sides need to retain the transmission identifier from the exchange and make it available where the Tax Data Document is built. This is the change most likely to require development work.

  2. Recalculate Invoice UUIDs using the method in the Invoice UUID calculation section, and verify your implementation against the published test vectors. Values derived from the earlier inputs, and any placeholder identifiers in existing test data, will no longer validate.

  3. Check issue times carry a time zone. Test data created while the time zone rule was defective may omit it.

  4. Review buyer-side test data. Tax Data Documents reported with role C3 now need the VAT totals and breakdown details listed above.

  5. Handle invoices without a Seller VAT identifier. Such invoices are exchanged onward as normal but are not reported: no Invoice UUID is calculated and no Tax Data Document is created.

  6. Re-validate existing Tax Data Documents against the corrected rules. The VAT breakdown rules for every VAT category, currency consistency (PEPPOL-EN16931-R051) and the document level German national rules were not previously executing. Documents that passed validation may now be rejected. Pay particular attention to the VAT exemption reason: categories AE, E, G, K and O require one, while S, Z, L and M must not carry one.

  7. Update to the version 1.1.0 validation artefacts — XML Schema and Schematron — and re-run your test suite.

Support

For support and clarification:

https://peppol.org/tools-support/service-desk/

Version 1.0.0-HotFix

Maintained by Peppol ViDA Pilot Team

Applies to

ViDA Tax Data Document

Release Date

2026-06-01

Status

Final

What’s New in This Release

This is version 1.0.0-HotFix of the ViDA Tax Data Document specification.

The release includes maintenance updates and a validation artefact hotfix to address a specification inconsistency identified during pilot implementation activities.

  • Updated the referenced PINT General specification version to 1.1.3 to align with the latest published code lists and validation artefacts.

  • Updated Self-Billing sample documents to remove UK-specific content and align examples with the European scope of the ViDA Pilot.

  • Temporarily disabled validation rule BR-IC-12.

Reason

  • A specification inconsistency was identified between the ViDA Tax Data Document Syntax Binding and the associated Schematron validation artefacts.

  • Validation rule BR-IC-12 requires the Deliver to country code (BT-80) to be present when the VAT category code (BT-118) is "Intra-community supply".

  • However, the current ViDA Tax Data Document Syntax Binding does not permit representation of the Delivery Location Country information required to satisfy the rule.

  • Consequently, Tax Data Documents generated from valid source invoices may fail validation despite being compliant with the published syntax.

Resolution

  • Validation rule BR-IC-12 has been temporarily disabled pending alignment of the Semantic Model, Syntax Binding, and Validation Artefacts.

Overview

This hotfix release addresses a specification inconsistency identified between the ViDA Tax Data Document Syntax Binding and the associated validation artefacts.

The issue affects validation rule BR-IC-12, which requires the Deliver to country code (BT-80) when the VAT category code (BT-118) is "Intra-community supply".

Although valid source invoices may contain the required delivery country information, the current ViDA Tax Data Document syntax does not provide a mechanism to represent this information. As a result, correctly generated Tax Data Documents can fail validation despite being compliant with the published syntax.

To prevent valid documents from being incorrectly rejected, validation rule BR-IC-12 has been temporarily disabled in this release.

This release also includes maintenance updates to the referenced PINT General specification and Self-Billing sample documents.

Validation Artefacts

  • Schematron Validation Rules:

    • Validation artefacts provide rule-based validation to ensure semantic and technical conformance.

    • The ViDA Tax Data Document Schematron rules validate structural and business-rule compliance.

    • This release introduces a temporary exception to the validation artefacts by disabling validation rule BR-IC-12.

    • The change ensures that documents conforming to the published Syntax Binding are not incorrectly rejected due to an identified specification inconsistency.

Documentation

  • ViDA Tax Data Document Documentation:

    • Updated references to PINT General version 1.1.3.

    • Updated Self-Billing sample documents.

    • Removal of UK-specific references from sample content.

    • Alignment of examples with the European scope of the ViDA Pilot.

Code Lists

  • Standard codelists:

    • Adapted from PINT General 1.1.3.

  • ViDA Tax Data Document:

    • Referenced code lists updated through alignment with PINT General version 1.1.3.

Schematron

Schematron artefacts provide rule-based validation to ensure semantic and technical conformance.

  • ViDA Tax Data Document Schematron:

    • Validation rule BR-IC-12 has been temporarily disabled.

    • The disabled rule is:

[BR-IC-12] In an Invoice with a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the Deliver to country code (BT-80) shall not be blank.

  • The rule was disabled because the current Syntax Binding does not support representation of the Delivery Location Country information required by the rule.

  • This change prevents technically compliant Tax Data Documents from being incorrectly rejected.

Technical Details

  • Current Delivery Information Representation:

<cac:Delivery>
    <cbc:ActualDeliveryDate>
</cac:Delivery>

  • Delivery Country Information Required by BR-IC-12:

<cac:DeliveryLocation>
    <cac:Address>
        <cac:Country>
            <cbc:IdentificationCode>
        </cac:Country>
    </cac:Address>
</cac:DeliveryLocation>

  • Impact:

    • The source invoice may be valid.

    • The Tax Data Document mapping may be correct.

    • The generated Tax Data Document may conform to the published Syntax Binding.

    • The document may still fail validation against BR-IC-12.

  • Temporary Resolution:

    • The corresponding Schematron assertion has been disabled.

    • The rule may be reintroduced in a future release once the Semantic Model, Syntax Binding, and Validation Artefacts have been aligned.

Action Items for Implementers

Implementers SHALL perform the following actions to ensure conformance:

  • Update validation artefacts to Version 1.0.0-HotFix.

  • Update referenced PINT General artefacts and code lists where applicable.

  • Update Self-Billing sample documents and associated test scenarios where applicable.

  • Continue validating implementations against the published validation artefacts, including:

    • XML Schema Definitions (XSD).

    • Updated Schematron rules.

  • No changes to existing Tax Data Document mappings are required as a result of this hotfix.

  • Monitor future releases for the reintroduction of BR-IC-12 following alignment of the Semantic Model, Syntax Binding, and Validation Artefacts.

Support

For support and clarification:

https://peppol.org/tools-support/service-desk/

Version 1.0.0

Maintained by Peppol ViDA Pilot team

Applies to

ViDA Tax Data Document

Release Date

2026-03-24

Status

Final

What’s New in This Release

This is version 1.0.0 of the ViDA Tax Data Document specification. The release includes the following components:

  • Tax Data Document BIS Documentation.

  • Semantic Model.

  • Syntax Binding.

  • Normative Codelists.

  • Tax Data Document-specific Schematron rules.

  • Referenced Schematron artefacts in use.

  • Changes in this version:

    • Enhanced Schematron validation logic for improved accuracy and maintainability.

    • Added support for Self-Billing scenarios.

    • Provided updated and improved sample documents for both Billing and Self-Billing.

    • Updated BIS identifiers, namespaces, and data types to align with the latest specifications.

    • Renamed tax data element from pxs:DocumentTypeCode to pxs:TaxDataTypeCode for improved clarity.

    • Fields updated from Mandatory to Optional (Peppol and CEN Schematron rules have been updated accordingly):

      • BG-05 (Supplier’s postal address).

      • BG-08 (Buyer’s postal address).

      • BT-110 (Invoice total VAT amount in document currency).

      • BG-23 (VAT BREAKDOWN).

      • BT-117 (VAT category tax amount).

      • BT-118 (VAT category code).

      • BG-30 (LINE TAX INFORMATION).

    • Included a sample demonstrating the transition of these fields from mandatory to optional.

Overview

This release introduces the first official version of the ViDA Tax Data Document Specification.

The specification defines:

  • The Semantic Model (business information requirements).

  • The Syntax Binding (technical representation).

  • BIS documentation and implementation guidance.

  • Applicable normative codelists.

  • Validation artefacts, including Schematron rules.

The objective of this release is to establish a clear and governable framework that ensures semantic consistency, validation accuracy, and implementation certainty for all stakeholders.

Data Model

  • Semantic Model:

    • A Semantic Model in Peppol is a structured, technology-independent representation of the business information, constraints, and relationships required for electronic document exchange, forming the authoritative source for syntax binding, validation rules, and conformance profiles.

      • Business Terms (what the information means).

      • Cardinality rules (how many times information may occur).

      • Data types and formats (how information is represented conceptually).

      • Business rules and constraints (conditions governing usage).

      • Relationships between business elements.

  • Syntax Binding:

    • A Syntax Binding in Peppol is the formally governed, technology-specific mapping of a Semantic Model to a concrete document syntax, defining the exact structural representation, cardinalities, data types, and validation constraints required for an implementation.

      • Technology-Specific Representation.

      • Deterministic Mapping.

      • Normative for Implementation.

      • Constrained by Peppol Governance.

Documentation

  • Peppol Model for Tax Data Document:

    • Introduction and Scope.

    • Audience and Benefits.

    • Business processes.

    • Technical details:

      • BIS Identifiers.

      • Data types.

      • XML Schemas and Namespaces.

      • Glossary.

  • Compliance:

    • Sending Compliance to TDD.

    • Receiving Compliance to TDD.

    • Enveloping Compliance.

Code Lists

  • Standard codelists:

    • UNCL5189 (Allowance reason code).

    • UNCL7161 (Charge reason code).

    • ISO3166-1:Alpha2 (Country codes).

    • ISO4217 (Currency codes).

    • UNCL2005 (Date/Time/Period code).

    • UNCL1001 (Credit note type code).

    • UNCL1001 (Invoice type code).

    • EAS (Electronic address scheme).

    • ICD (ISO 6523 ICD list).

    • UNCL7143 (Item type identification code).

    • UNCL4461 (Payment means code).

    • UNECERec20 (Unit codes).

    • VATEX (VATEX code list).

  • ViDA:

    • ViDATaxCat (ViDA VAT category codes).

  • Tax Data Document:

    • TDD-RR (Tax Data Document Reporting Role).

    • TDD-DS (Tax Data Document Scope).

    • TDD-DTC (Tax Data Document Type Code).

Schematron

Schematron artefacts provide rule-based validation to ensure semantic and technical conformance.

  • CEN EN 16931:

    • The CEN EN 16931 Schematron rules define automated validation constraints aligned with the European semantic data model for electronic invoices.

    • These rules verify:

      • Compliance with mandatory business terms.

      • Cardinality constraints.

      • Code list validity.

      • Mathematical consistency (e.g. VAT calculations, totals).

    • Their purpose is to ensure legally compliant cross-border electronic invoicing within the EU.

  • Peppol EN 16931:

    • The Peppol EN 16931 Schematron rules extend the core CEN EN 16931 validation set with additional interoperability and network-specific constraints required for Peppol participants.

    • These rules enforce:

      • Additional usage restrictions.

      • Peppol-specific code list limitations.

      • Network-level business rules.

    • Their purpose is to ensure consistent semantic interpretation and interoperability across the Peppol network.

  • Tax Data Document Choreography:

    • The Tax Data Document Choreography Schematron rules validate structural and choreography-level compliance.

    • These rules ensure that:

      • The document strictly follows the defined Syntax Binding.

      • Only permitted elements and structures are used.

      • No undefined or non-conformant elements are introduced.

    • Their purpose is to guarantee technical conformance to the specified document structure.

Action Items for Implementers

Implementers SHALL perform the following actions to ensure conformance:

  • Review and understand the Semantic Model and the associated Syntax Binding before implementation.

  • Ensure that all code values strictly comply with the applicable normative codelists.

  • Validate implementations against the published validation artefacts, including:

    • XML Schema Definitions (XSD).

    • Schematron rules.

  • Develop the Tax Data Document in full compliance with the Semantic Model, Syntax Binding, and validation artefacts.

  • Notify the relevant Peppol Authority of any identified critical defects, inconsistencies, or required change requests.

Support

For support and clarification:

https://peppol.org/tools-support/service-desk/

Version 0.9.0

Maintained by Peppol ViDA Pilot team

Release Date

2025-12-12

Status

Review

What’s new in this release?

  • XSD Schema and Schematron improvements.

  • Documentation: Peppol ViDA model for Tax Data Document updates.

  • Bug fixes.

  • cbc:DocumentCurrencyCode (TDT-008) Removed from TDD part.

  • TDD namespace aligned with ViDA.

  • Enhancements to the semantic model and associated syntax bindings.

  • Updates to documentation, including compliance guidance.

  • Introduction of standardized code lists.

  • Addition of XSD schemas and Schematron validation artifacts.

  • Improved traceability by linking business rules to the TDD structure.

Version Information

ViDA Tax Data Document 0.9.0

Applies to

ViDA Tax Data Document

Reviewed

-