As electronic invoicing becomes the standard method of invoice exchange across Europe, businesses must understand the structure behind compliant invoices. While many organizations focus on formats such as XRechnung or ZUGFeRD, the foundation of these formats is the EN 16931 data model.
The EN 16931 data model defines how invoice information should be organized, validated, and exchanged between systems. Rather than focusing on the visual appearance of an invoice, it defines the business information that must be included and how each data element relates to others. This common structure supports interoperability between ERP systems, accounting applications, procurement platforms, and e-invoicing networks.
For organizations operating in Germany, understanding the EN 16931 data model helps improve invoice quality, support compliance, and simplify electronic invoice processing.
Key Takeaways
Greece E-Invoicing Deadline 2026: Applies to all VAT-registered businesses regardless of size.
Sales invoice reporting: Sales invoices must typically be reported to myDATA on the day of issuance or within the VAT period.
Purchase invoice classification: Purchase invoice classification deadlines align with the periodic VAT return filing date.
Greece Mandatory E-Invoicing: Covers both B2B and B2G transactions within the myDATA framework.
AADE E-Invoicing Timeline: Is updated annually via AADE circulars and technical bulletins.
myDATA Reporting Deadlines: Deadlines for corrections and credit notes follow specific AADE-defined windows.
How the EN 16931 Data Model Is Structured
The EN 16931 Data Model organizes invoice information into a logical and standardized structure.
Instead of allowing businesses to create invoices using different field definitions, the standard establishes a common framework that software systems can interpret consistently. This ensures invoice data retains the same meaning regardless of the platform used to generate or receive it.
The model is designed around business information rather than technical file structures. As a result, organizations can exchange invoices using different XML syntaxes while still complying with the same underlying business requirements.
This approach enables widespread interoperability across industries, countries, and technology environments.
Core Structure Components
| Component | Purpose |
|---|---|
| Business Terms | Individual data fields |
| Business Groups | Collections of related fields |
| Validation Rules | Ensure compliance |
| Code Lists | Standardized values |
| Syntax Bindings | Technical implementation |
What Are Business Terms (BT) and Business Groups (BG)?
The EN 16931 Data Model uses Business Terms (BT) and Business Groups (BG) as its primary building blocks.
Business Terms represent individual pieces of invoice information. Examples include invoice numbers, invoice dates, supplier names, customer references, tax identifiers, and payment information.
Business Groups organize related Business Terms into logical sections. Rather than treating all invoice information as individual fields, the model groups related information together for consistency and easier validation.
This hierarchical approach simplifies invoice processing because systems can identify where specific business information belongs within the overall document structure.
Understanding the relationship between Business Terms and Business Groups is essential for businesses implementing compliant e-invoicing solutions.
Example Structure
| Element Type | Example |
|---|---|
| Business Term | Invoice Number |
| Business Term | Invoice Date |
| Business Term | Supplier Name |
| Business Group | Seller Information |
| Business Group | Buyer Information |
| Business Group | VAT Breakdown |
Mandatory Fields in the Core Invoice Model
The EN 16931 Data Model contains mandatory fields that must be present for an invoice to meet compliance requirements.
These mandatory elements ensure that recipients can identify the transaction, process the invoice correctly, and meet reporting obligations. Missing information can lead to validation failures and invoice rejection.
Required information generally includes supplier details, buyer information, invoice references, tax information, payment instructions, and summary totals.
Organizations should ensure that accounting systems, ERP solutions, and e-invoicing platforms consistently populate mandatory fields before invoices are transmitted.
Failure to provide required information is one of the most common causes of validation errors.
Examples of Mandatory Information
| Information Area | Purpose |
|---|---|
| Invoice Identifier | Unique invoice reference |
| Issue Date | Identifies invoice creation date |
| Seller Information | Supplier identification |
| Buyer Information | Customer identification |
| VAT Information | Tax reporting requirements |
| Invoice Totals | Financial summary |
Invoice Header, Seller, Buyer and Line Fields
The EN 16931 Data Model separates invoice information into several major sections to improve consistency and processing efficiency.
The invoice header contains general document information such as invoice identifiers, issue dates, and invoice types. This information helps receiving systems classify and process invoices correctly.
Seller and buyer sections contain information about the organizations involved in the transaction. These areas identify the parties responsible for issuing and receiving the invoice.
Invoice line sections provide detailed information about the supplied goods or services. Each line can contain descriptions, classification information, VAT details, and quantity references where applicable.
This structured approach allows systems to process invoice information automatically and consistently.
Main Invoice Sections
| Section | Function |
|---|---|
| Header | Document identification |
| Seller | Supplier details |
| Buyer | Customer information |
| Invoice Lines | Goods and services |
| VAT Section | Tax information |
| Totals | Invoice summary |
VAT Breakdown (BG-23) and Document Totals (BG-22)
The EN 16931 Data Model contains dedicated business groups specifically designed for tax reporting and invoice summary information.
BG-23 represents the VAT Breakdown section. This group records tax information associated with invoice transactions and ensures that VAT treatment is presented in a structured format.
BG-22 represents Document Totals. This section summarizes invoice-level information and provides an overview of calculations contained within the document.
These business groups are particularly important because they support automated validation and accounting processes. Financial systems rely on these structured sections to process tax information accurately.
Organizations should ensure VAT data remains consistent across invoice lines, VAT summaries, and overall document totals.
Important Business Groups
| Business Group | Purpose |
|---|---|
| BG-22 | Document totals |
| BG-23 | VAT breakdown |
| BG-24 | Additional information |
| BG-25 | Invoice line details |
| BG-4 | Seller information |
| BG-7 | Buyer information |
Code Lists: Currency, Country, VAT Category and Units
The EN 16931 Data Model relies on standardized code lists to ensure consistency across different systems and countries.
Instead of allowing free-text entries for certain information, code lists provide predefined values that improve interoperability and reduce ambiguity.
Common code lists cover areas such as currencies, countries, units of measure, and VAT categories. Because all compliant systems use the same reference values, invoice interpretation becomes more reliable.
Code lists also support automated validation. Systems can quickly identify invalid entries and reject invoices that do not comply with the required standards.
Maintaining accurate master data helps organizations avoid common code-list related validation issues.
Common Code Lists
| Code List Category | Purpose |
|---|---|
| Currency Codes | Identify invoice currency |
| Country Codes | Standardized country references |
| VAT Categories | Tax classification |
| Unit Codes | Measurement standards |
| Invoice Type Codes | Document classification |
How the Data Model Supports XRechnung and ZUGFeRD
The EN 16931 Data Model serves as the foundation for Germany’s most widely used electronic invoice formats.
XRechnung uses the model to provide structured invoice information suitable for public-sector invoicing. Validation rules ensure that required business information is available and correctly organized.
ZUGFeRD also relies on the same business model while combining structured invoice data with a human-readable PDF representation.
Because both formats are built upon the same underlying standard, they can exchange consistent invoice information even though their presentation methods differ.
This common foundation helps businesses communicate electronically with customers, suppliers, and government entities while maintaining compliance.
Format Relationship
| Format | Relationship to EN 16931 |
|---|---|
| XRechnung | Built on EN 16931 |
| ZUGFeRD | Uses EN 16931 structure |
| UBL | Supports data model implementation |
| CII | Supports data model implementation |
Common Data Quality and Validation Challenges
The EN 16931 Data Model supports automation, but successful implementation depends heavily on data quality.
Missing information remains one of the most common causes of invoice validation failures. Incomplete supplier details, missing references, or inconsistent tax information can prevent invoice processing.
Organizations may also experience issues when ERP systems contain outdated master data. If source information is inaccurate, even technically correct invoices may fail compliance checks.
Validation tools help identify these problems before invoices are exchanged with trading partners or government entities.
Businesses that invest in strong data governance generally achieve smoother implementations and more reliable invoice processing results.
Common Validation Issues
| Issue | Impact |
|---|---|
| Missing Mandatory Fields | Validation failure |
| Incorrect Code Values | Invoice rejection |
| Incomplete Master Data | Processing delays |
| VAT Inconsistencies | Compliance concerns |
| Duplicate References | Workflow issues |
Conclusion
The EN 16931 data model provides the structured foundation that enables electronic invoices to be exchanged consistently across businesses, governments, and software platforms. Through the use of Business Terms, Business Groups, mandatory fields, and standardized code lists, the model supports reliable automation and interoperability.
Organizations that understand the structure of the data model are better prepared to implement compliant invoicing processes, improve invoice quality, and reduce validation issues. As e-invoicing adoption continues to expand throughout Germany and Europe, a strong understanding of the underlying invoice model will remain essential for long-term compliance and operational efficiency.
Frequently Asked Questions
Q: What is the EN 16931 data model?
It is the structured business framework that defines the information required within a compliant electronic invoice.
Q: What are Business Terms?
Business Terms are individual invoice data elements such as invoice numbers, dates, supplier information, or tax details.
Q: What are Business Groups?
Business Groups organize related Business Terms into logical sections within an invoice.
Q: Why are mandatory fields important?
Mandatory fields ensure that invoices contain the information required for processing, reporting, and validation.
Q: What is BG-22?
BG-22 is the business group used for document totals within the invoice structure.
Q: What is BG-23?
BG-23 is the business group responsible for VAT breakdown information.
Q: Why are code lists used?
Code lists provide standardized values that improve interoperability, validation accuracy, and automated processing.
Source by:
Image by Gemini
