Key Takeaways
The relationship between e-invoicing and GoBD has become a key compliance topic since mandatory electronic invoicing was introduced in the German B2B sector. Since 1 January 2025, domestic businesses have generally been required to have the technical capability to receive structured e-invoices. It is therefore no longer sufficient to focus solely on creating or transmitting XRechnung, ZUGFeRD and other structured formats. Companies must also ensure that invoice receipt, validation, processing, posting, retention and data access comply with the GoBD.
The definition of e-invoicing and GoBD can therefore be summarised as follows: An e-invoice is a structured electronic invoice data set. The GoBD govern how tax-relevant electronic information must be processed and retained within a company’s data processing systems in a traceable, complete, accurate, timely, orderly and immutable manner. E-invoicing and GoBD therefore do not refer to a separate invoice format, but to the interaction between legally compliant e-invoicing technology, proper accounting and documented processes.
Five points are particularly important in practice:
- The structured component of an e-invoice must be retained and must not be lost through conversion into PDF, TIFF or another image format.
- For hybrid e-invoices such as ZUGFeRD, the XML component must generally be retained. The PDF component is additionally required if it contains supplementary or differing information relevant for tax purposes.
- Under current legislation, invoices and accounting records must generally be retained for eight years—not ten years in every case.
- The procedural documentation must clearly describe the actual process from invoice creation or receipt through archiving, retrieval and machine readability.
- Software alone does not make a company GoBD-compliant. Compliance depends on the configured overall system, authorisations, controls, processes and their documented application.

Table of Contents
- Definition of E-Invoicing and GoBD: What Does GoBD-Compliant E-Invoicing Mean?
- Why Has GoBD-Compliant E-Invoicing Been Particularly Important Since 2025?
- E-Invoicing and GoBD at a Glance
- Legal Framework for E-Invoicing and GoBD
- Which GoBD Requirements Apply to E-Invoices?
- How Can Businesses Archive E-Invoices in Compliance with GoBD and Audit Requirements?
- Is It Sufficient to Save an E-Invoice as a PDF?
- Must Both the XML File and PDF Be Archived for ZUGFeRD?
- How Long Must E-Invoices Be Retained Under the GoBD?
- How Are Authenticity, Integrity and Readability Verified?
- What Are the Requirements for Procedural Documentation?
- Processing Inbound and Outbound E-Invoices in Full Compliance with GoBD
- Implementing GoBD-Compliant E-Invoicing with SAP
- Which E-Invoicing Software Is Suitable for SMEs?
- What Happens During a Tax Audit If GoBD Deficiencies Exist?
- Best Practices for GoBD-Compliant E-Invoicing
- Common Mistakes in GoBD-Compliant E-Invoicing
- Step by Step to a GoBD-Compliant E-Invoice Process
- Benefits of a GoBD-Compliant E-Invoicing Architecture
- Conclusion
- FAQ
Definition of E-Invoicing and GoBD: What Does GoBD-Compliant E-Invoicing Mean?
The GoBD are the “Principles for Properly Maintaining and Retaining Books, Records and Documents in Electronic Form and for Data Access” published by the German Federal Ministry of Finance. They specify how the requirements of the German Fiscal Code and commercial law apply to digitally maintained books, records, supporting documents and upstream systems. The GoBD apply not only to Financial Accounting, but also to upstream and subsidiary systems in which tax-relevant data is created, processed or stored.
An e-invoice, by contrast, is an invoice issued in a structured electronic format that enables automated electronic processing. In Germany, XRechnung and ZUGFeRD from version 2.0.1 onwards—excluding the MINIMUM and BASIC-WL profiles—generally meet the VAT-related format requirements.
E-invoicing and GoBD bring these two levels together:
- The invoice must comply with the applicable VAT requirements in terms of both content and form.
- The structured data set must be generated or received correctly.
- Processing must be traceable and controlled.
- Changes must either be prevented or fully logged.
- Tax-relevant data must remain available, readable and machine-evaluable throughout the entire retention period.
GoBD-compliant e-invoicing therefore involves far more than simply placing an XML file in an archive. It concerns the proper design of the entire process—from the underlying business transaction through invoicing and posting to a subsequent tax audit.
Why Has GoBD-Compliant E-Invoicing Been Particularly Important Since 2025?
The GoBD already applied to electronic accounting and retention processes before the introduction of mandatory B2B e-invoicing. However, the requirement to receive e-invoices since 2025 has placed considerably greater emphasis on the structured data set. For this reason, the Federal Ministry of Finance explicitly amended the GoBD on 14 July 2025 and incorporated terms such as “XML file” and “structured component of an e-invoice” into the administrative guidance.
The amendment is relevant for businesses because it clarifies several frequently discussed issues:
- The structured data component is decisive for an e-invoice.
- A purely visual copy is not sufficient if the XML content is lost.
- For a hybrid e-invoice, retaining the structured component may be sufficient.
- Electronic documents received by a company must generally be retained in their incoming format.
- Where OCR or other technologies create additional verified information, this information may also become subject to retention requirements.
Companies should therefore review their existing PDF, archive and document management processes. A process that may previously have appeared sufficient for scanned paper invoices or PDF invoices is not automatically suitable for retaining structured e-invoices unchanged and in a machine-evaluable format over many years.
E-Invoicing and GoBD at a Glance
| Topic | Current Requirement |
|---|---|
| Relevant invoice component | Structured data set, usually XML |
| Incoming e-invoice | Generally retain it in the format received |
| ZUGFeRD / hybrid format | Retain the XML; retain the PDF as well if it contains additional tax-relevant information |
| Retention period | Generally eight years |
| Changes | Permitted only if traceable and logged |
| Availability | Throughout the entire retention period |
| Readability | Must be ensured through an appropriate rendering or viewer |
| Machine evaluability | Structured data and links must be retained |
| Procedural documentation | Current, understandable and version-controlled |
| Software certification | No GoBD certification is binding on the tax authorities |
This overview reflects the current versions of Section 14b of the German VAT Act, Section 147 of the German Fiscal Code, Section 257 of the German Commercial Code and the GoBD as amended in 2025.
Legal Framework for E-Invoicing and GoBD
The requirements do not arise from a single regulation. Several legal and administrative layers interact.
German VAT Act
Section 14 of the German VAT Act governs invoice requirements. The authenticity of origin, integrity of content and readability must be ensured. Companies may satisfy these requirements through internal control procedures that establish a reliable audit trail between the invoice and the underlying supply or service. A qualified electronic signature is therefore not mandatory in every case.
Section 14b of the German VAT Act governs invoice retention. Under the current wording, issued and received invoices must generally be retained for eight years.
German Fiscal Code
Section 147 of the German Fiscal Code requires, among other things, the orderly retention of accounting records. Electronically stored data must remain available, immediately readable and machine-evaluable throughout the retention period. Accounting records must generally be retained for eight years.
German Commercial Code
Section 257 of the German Commercial Code also provides for an eight-year retention period for accounting records. Different ten-year requirements may apply to certain regulated entities, including financial institutions and insurance companies.
GoBD
The GoBD specify how electronic accounting, processing and archiving procedures must be designed. Relevant principles include traceability, completeness, accuracy, timely recording, orderliness, immutability, data security and data access.
Which GoBD Requirements Apply to E-Invoices?
Traceability and Auditability
The complete path from the invoice document to the accounting entry, tax return and analysis must be traceable. Conversely, it must also be possible to trace an accounting entry back to the original e-invoice. This forward and backward auditability must be maintained throughout the entire retention period.
For GoBD-compliant e-invoicing, this means that the XML data set, posting, business partner, approvals, validation results and, where applicable, the purchase order or proof of service should be clearly linked.
Completeness and Accuracy
All relevant business transactions must be recorded completely and accurately. Control mechanisms should identify missing data sets, duplicate invoice numbers, inconsistent tax information and incomplete mandatory fields.
According to the Federal Ministry of Finance, technical format validation is not necessarily an immediate prerequisite for tax recognition in every case. Nevertheless, it is a useful control because it can identify syntax errors, missing information and implausible values at an early stage.
Timely Safeguarding of Documents
E-invoices should be protected against loss and uncontrolled alteration as soon as reasonably possible after receipt or creation. An unattended email inbox or freely writable network drive is therefore generally not a reliable long-term solution.
Orderly Storage and Retrievability
Invoices must be stored systematically, indexed clearly and retrievable within a reasonable period. Suitable search criteria include the invoice number, business partner, company code, document number, invoice date, amount and tax period.
Immutability
Information that has entered the processing workflow must not be overwritten, deleted or altered without detection. Subsequent changes are permitted only if the original content and change history remain identifiable. The GoBD refer to technical, software-based and organisational measures such as locks, finalisation, versioning, logging and authorisation concepts. A standard file repository will generally not meet these requirements without additional safeguards.
Data Security
Companies must protect their data against loss, destruction, theft and unauthorised modification. This includes role and authorisation concepts, backup and recovery processes, logging, protection against unnoticed deletion and controlled procedures for system changes.
How Can Businesses Archive E-Invoices in Compliance with GoBD and Audit Requirements?
The term “audit-proof” is widely used in the market. However, compliance does not depend on one technical feature alone. What matters is whether the complete process satisfies the legal and GoBD requirements.
A robust archiving procedure will typically include the following steps:
1. Retain the Original Structured Data Set
An incoming XRechnung or other XML invoice should be retained in the format in which it was received. The structured data set must not be replaced solely by a conversion into PDF or TIFF. Under the current GoBD, incoming electronic accounting documents must generally be retained in their incoming format. Permitted conversions must preserve content, traceability and evaluability.
2. Validate the Invoice
A technical and business validation can determine whether the file is readable, complies with the expected syntax and contains the required invoice information. The validation result should be linked to the invoice document or the relevant process object.
3. Protect the Invoice Against Changes at an Early Stage
After receipt, the e-invoice should promptly be transferred into a controlled document management or archiving process. Changes to the original should be blocked, while supplementary processing information should be stored separately or under traceable version control.
4. Link the Invoice to Posting and Process Data
The e-invoice should be clearly linked to the accounting document, purchase order, goods receipt, approvals and any subsequent corrections. This establishes a reliable audit trail.
5. Ensure Readability
Raw XML invoices are difficult for users to interpret. Companies must therefore provide an appropriate rendering or viewer without altering the structured original data set. Under Section 147 of the German Fiscal Code and the GoBD, electronic documents must remain capable of being rendered in a readable form throughout the retention period.
6. Preserve Machine Evaluability
The structured file, relevant metadata, master data and links must be retained in a way that allows them to be evaluated during a tax audit. Screenshots, printed views and reports are not sufficient if relevant data structures are lost.
Is It Sufficient to Save an E-Invoice as a PDF?
No. If an e-invoice is received as a structured XML file, a PDF rendering generated from it is generally not a sufficient substitute for the structured data set.
Although the PDF makes the invoice readable for users, it typically removes the structured, machine-evaluable information. A format conversion must not result in the legally and functionally relevant XML component being deleted. The Federal Ministry of Finance expressly states that at least the structured component of an e-invoice must be retained intact in its original form.
A PDF visualisation may be useful as an additional document for internal reviews, approvals or quick display. However, it must not be confused with the original data set.
Must Both the XML File and PDF Be Archived for ZUGFeRD?
The GoBD amendment effective from 14 July 2025 provides important clarification. For a hybrid e-invoice such as ZUGFeRD, retaining the structured component is generally sufficient. The human-readable PDF component must also be retained if it contains further or differing information relevant for tax purposes—for example, posting notes.
In practical terms:
- The embedded XML data set must never be lost.
- If the PDF and XML contain the same tax-relevant information, the structured component is primarily decisive for tax purposes.
- If the PDF contains additional relevant information, that information must also be retained.
- From an operational perspective, it is often advisable to archive the original hybrid document unchanged, thereby preserving the PDF, XML and their technical relationship.
This recommendation is particularly relevant for companies that want to archive e-invoices in compliance with GoBD while also providing users with a straightforward visual representation.
How Long Must E-Invoices Be Retained Under the GoBD?
Under current legislation, the regular retention period for invoices and accounting records is generally eight years. The period begins at the end of the calendar year in which the invoice was issued or the accounting record was created.
Example: An invoice issued in May 2026 must generally be retained until the end of 2034.
Important: Older articles frequently refer to a ten-year retention period. That statement is no longer current for general invoice retention. In individual cases, the effective period may nevertheless be longer if the documents remain relevant for taxation and the applicable tax assessment limitation periods have not yet expired.
How Are Authenticity, Integrity and Readability Verified?
Section 14(3) of the German VAT Act requires the authenticity of origin, integrity of content and readability of an invoice to be ensured.
- Authenticity of origin means that the identity of the invoice issuer is assured.
- Integrity of content means that the VAT-related mandatory information has not been altered without detection.
- Readability means that the invoice can be presented in an understandable form for audit purposes.
These requirements may be satisfied through an internal control procedure that establishes a reliable audit trail between the invoice and the underlying supply or service. This may include matching the invoice against the purchase order, contract, goods receipt, service entry, supplier data and payment information.
An electronic signature may be used, but it is not mandatory in every case. What matters is that the selected procedure effectively satisfies the requirements and is documented in a traceable manner.
What Are the Requirements for Procedural Documentation?
Clearly structured procedural documentation must exist for every relevant IT system. It should provide a complete and coherent description of the content, structure, operation and results of the process used. The required level of detail depends on the complexity of the company, its organisation and the systems involved.
Procedural documentation for e-invoicing and GoBD should address the following areas in particular:
Inbound and Outbound Processes
- Which e-invoice formats are received and generated?
- Through which channels do invoices enter the company or reach the recipient?
- Which systems and service providers are involved?
Validation and Processing
- Which technical and business validations are performed?
- How are defective invoices handled?
- How are posting proposals, approvals and corrections generated?
Archiving
- Which data set is retained?
- How is immutability ensured?
- How do indexing, retrieval and rendering work?
- Which retention and deletion rules apply?
Authorisations and Controls
- Who may view, edit, approve or export invoices?
- Which controls and logs are available?
- How are changes to configurations and master data documented?
System Operation and Changes
- Which software versions are used?
- How are updates, migrations and system changes performed?
- How is it demonstrated that the documented target process corresponds to the actual process in operation?
The GoBD identify a general description, user documentation, technical system documentation and operating documentation as typical components. Changes must be version-controlled and historically traceable. However, missing or inadequate procedural documentation does not automatically result in the rejection of the accounting records if traceability and auditability are not impaired in the specific case.
Processing Inbound and Outbound E-Invoices in Full Compliance with GoBD
Inbound Invoices
For incoming e-invoices, the process from the input channel through posting should be documented end to end. The invoice is received, technically validated, rendered where necessary, reviewed from a business perspective, approved, posted and archived. The original data set and relevant processing information remain linked.
For outgoing invoices, the structured invoice data must be generated correctly from the source systems, validated and transmitted. Under certain conditions, the updated 2025 GoBD guidance permits companies not to retain a permanent visual copy of an outbound invoice, provided that an identical duplicate can be generated at any time. However, the tax-relevant structured data set and the traceability of the creation process remain decisive.
Outbound Invoices
Transmission and Email
Where an email serves solely as a transmission medium, the invoice attachment is the primary document. However, if the message itself contains business or tax-relevant information, it should also be included in the assessment of retention and documentation requirements.
Implementing GoBD-Compliant E-Invoicing with SAP
A robust SAP architecture should clearly distinguish between e-invoicing compliance, invoice workflow and archiving.
SAP Document and Reporting Compliance
SAP Document and Reporting Compliance supports the creation, processing and monitoring of electronic documents and statutory reports. Depending on the supported scenario, outgoing invoices can be converted into electronic documents and incoming supplier invoices can be processed. SAP also provides for integration with an incoming automation solution to support the end-to-end process.
It is important to understand that SAP DRC is not automatically a complete GoBD archive. The solution supports format, transmission, status and compliance processes. A supplementary archiving or content management layer is generally required for long-term, rules-based retention.
Further information:
SAP Invoice Management by OpenText
SAP Invoice Management by OpenText digitises and automates accounts payable processes. The solution supports data capture, workflows, approvals, transparency and integration with SAP ERP, among other capabilities. OpenText describes VIM as a solution deeply integrated into SAP for document-driven processes and workflows.
The same principle applies here: Workflow functionality is not the same as archiving. To retain e-invoices in compliance with GoBD, VIM must be connected to an appropriate content or archive solution and configured with suitable retention rules.
Further information:
SAP ArchiveLink and SAP ILM
SAP ArchiveLink connects SAP business objects with documents stored in an external archive. The SAP system maintains a logical link between the business object—for example, an invoice document—and the technical archive object.
SAP Information Lifecycle Management can additionally be used for rules-based retention and deletion concepts. The available objects and functions depend on the product, release, country scenario and specific implementation. SAP documents, for example, dedicated archiving objects for electronic invoice XML files and ILM-based retention rules.
A typical target architecture may therefore consist of the following components:
- SAP ERP or SAP S/4HANA as the leading business system
- SAP DRC for electronic documents, formats and statutory communication
- SAP Invoice Management by OpenText for the inbound invoice workflow
- SAP ArchiveLink, OpenText Content Management or a comparable archiving solution
- SAP ILM or another retention management solution for retention and deletion rules
- Viewer, data export, monitoring and procedural documentation
Which E-Invoicing Software Is Suitable for SMEs?
Suitable software should not be selected solely on the basis of a marketing claim such as “GoBD-certified”. The tax authorities make clear that they do not issue generally valid approvals for hardware or software. Third-party certificates may support the selection process, but they are not binding on the tax authorities.
The following criteria are particularly relevant for small and medium-sized businesses:
- Receipt and transmission of XRechnung and ZUGFeRD
- Retention of the original structured data set
- Immutable or traceably version-controlled storage
- Role and authorisation concept
- Complete audit trail
- Search by invoice and accounting characteristics
- XML viewer and human-readable rendering
- Data export for tax audits
- Rules-based retention and deletion
- Interfaces to Accounting, ERP and tax advisers
- Support for procedural documentation and system changes
- Backup, restart and migration concepts
The right GoBD-compliant e-invoicing solution depends on invoice volume, ERP landscape, international operations, internal controls and collaboration with the company’s tax adviser.
What Happens During a Tax Audit If GoBD Deficiencies Exist?
Deficiencies do not automatically lead to a tax estimate or the loss of input VAT deduction. Their nature, extent and material significance are decisive.
If a company cannot provide relevant invoices, data or links, the formal reliability of its accounting records may be challenged. If the tax authority is therefore unable to determine the taxable basis reliably, an estimate under Section 162 of the German Fiscal Code may be considered.
In practice, non-compliant processes may lead to:
- Longer audits
- Additional data requests
- Time-consuming reconstruction work
- Doubts regarding completeness or immutability
- Objections to the internal control system
- In serious cases, rejection of records as a reliable basis for taxation
At the same time, the Federal Ministry of Finance clarifies that inadequate procedural documentation alone does not necessarily constitute a materially significant deficiency if traceability and auditability remain assured.
Best Practices for GoBD-Compliant E-Invoicing
Companies should design their processes as close to standard as possible and across systems:
- Retain structured invoice data in its original form.
- Link validation results to the invoice document.
- Protect e-invoices against loss and alteration at an early stage.
- Clearly link the invoice, accounting entry, purchase order, approval and payment.
- Assign permissions based on roles and responsibilities.
- Log all changes, corrections and cancellations completely.
- Ensure that XML files can be rendered and exported in a machine-evaluable format at any time.
- Test archiving, backup and recovery procedures regularly.
- Update procedural documentation whenever relevant systems or processes change.
- Manage retention and deletion rules centrally.
Common Mistakes in GoBD-Compliant E-Invoicing
Saving Only the PDF Rendering
This causes the structured and machine-evaluable original data set to be lost.
Storing XML Files on an Uncontrolled Drive
A freely writable file system will generally not satisfy immutability requirements without additional controls.
Failing to Document Format Conversions
Where files are converted, enriched or migrated, their content, evaluability and change history must remain traceable.
Equating GoBD Compliance with a Certificate
Software attestations are not binding. The company remains responsible for configuration, use, data quality and process controls.
Treating Procedural Documentation as a One-Off Project
It must reflect the actual current process and document all relevant changes in a historically traceable manner.
Treating DRC, VIM and the Archive as Identical Functions
These systems perform different tasks. Only their coordinated interaction creates a robust end-to-end process.
Step by Step to a GoBD-Compliant E-Invoice Process
Step 1 – Identify the Relevant Processes and Systems
Document all inbound and outbound channels, formats, ERP systems, accounting solutions, portals, service providers and archives.
Step 2 – Define the Target Process
Define how invoice receipt, validation, approval, posting, archiving, correction, cancellation and data access should operate.
Step 3 – Safeguard the Original Format and Data Model
Define which files and metadata must be retained. For XRechnung, this is the XML data set. For ZUGFeRD, it is at least the structured component and, where applicable, additional tax-relevant PDF content.
Step 4 – Establish Controls
Configure syntax and business rule validation, duplicate checks, supplier matching, approvals, authorisations, logging and escalation procedures.
Step 5 – Configure the Archive and Retention Rules
Implement retention periods, locks, search criteria, export functions, deletion rules, backups and recovery procedures.
Step 6 – Create Procedural Documentation
Describe the organisation, user process, technology, operations, authorisations, controls, interfaces, archiving and change history.
Step 7 – Test the Process End to End
Test standard invoices, defective XML files, cancellations, corrections, system outages, data exports and the rendering of older invoices.
Step 8 – Monitor and Improve Operations
Regularly review error rates, cycle times, open workflow items, access logs, archive exports and changes in legislation.
Benefits of a GoBD-Compliant E-Invoicing Architecture
A properly implemented GoBD-compliant e-invoicing process is not merely a compliance measure. It also improves finance operations.
Companies benefit from:
- Higher data quality
- Less manual data entry
- Faster approvals
- Improved auditability
- Reduced search and reconstruction effort
- Stronger audit readiness
- Clearly defined responsibilities
- A robust foundation for automation, AI and international e-invoicing rollouts
Structured invoice data is particularly valuable because it supports automated validation and direct downstream processing. SAP DRC can create, process and monitor electronic documents, while SAP Invoice Management by OpenText supports the automation of accounts payable processes.
Conclusion
GoBD-compliant e-invoicing means not only sending or receiving structured invoice data correctly, but processing it properly throughout its entire lifecycle.
The most important conclusions are:
- The structured data component is the central original of an e-invoice.
- A PDF copy does not replace the XML data set.
- For ZUGFeRD, the structured component is generally sufficient, but tax-relevant supplementary information in the PDF must also be retained.
- The current standard retention period is eight years.
- Traceability, immutability, availability and machine evaluability must be safeguarded through both technical and organisational measures.
- Procedural documentation must describe the actual process in an understandable, current and version-controlled manner.
- There is no software “GoBD certification” that is binding on the tax authorities.
- SAP DRC, SAP Invoice Management, ArchiveLink, ILM and content archives perform different functions and should be combined within a coordinated target architecture.
Companies that establish a robust GoBD-compliant e-invoicing solution at an early stage reduce audit risks while creating a stronger foundation for automated invoice processing, international compliance and future digital reporting obligations.
FAQ
What Does GoBD-Compliant E-Invoicing Mean?
GoBD-compliant e-invoicing describes the proper processing and retention of structured electronic invoices in accordance with the GoBD, the German VAT Act, the German Fiscal Code and, where applicable, the German Commercial Code.
How Can I Archive an E-Invoice in Compliance with GoBD?
Retain the original structured data set unchanged or under traceable protection, link it to the accounting entry, preserve readability and machine evaluability, and document the complete process.
Which GoBD Requirements Have Applied Since 2025?
Since the GoBD amendment of 14 July 2025, structured e-invoice data has been addressed explicitly. In particular, the guidance clarifies that the structured component is decisive for hybrid e-invoices.
Is It Sufficient to Save an E-Invoice as a PDF?
No. If the invoice was received as structured XML, the structured data set must be retained.
How Long Must E-Invoices Be Retained?
Invoices and accounting records must generally be retained for eight years. The period begins at the end of the calendar year in which the invoice was issued or the accounting record was created.
Must Both the PDF and XML Be Archived for ZUGFeRD?
The structured XML component must be retained. The PDF must additionally be retained if it contains further or differing tax-relevant information.
What Should Be Included in Procedural Documentation?
It should describe the organisational and technical process from invoice receipt or creation through validation, processing, archiving, retrieval, data security and evaluability to deletion.
Is an Electronic Signature Required?
Not necessarily. Authenticity, integrity and readability can also be ensured through an internal control procedure with a reliable audit trail.
Is GoBD-Certified Software Available?
Third-party certificates can provide guidance, but they are not binding on the tax authorities. Software alone therefore does not guarantee GoBD compliance.
What Happens If Archiving Is Not GoBD-Compliant?
Depending on the severity of the deficiency, the tax authorities may request additional evidence, challenge the reliability of the records and, where the taxable basis cannot be determined, perform an estimate. Not every formal deficiency automatically leads to such consequences.