E-invoice declaration: What should it include to be audit-compliant?

In e-invoicing projects, it is surprisingly common for the technical aspects (invoicing system, XML, tax authority data reporting, archiving) to be completed, while the documentation of partner acceptance remains incomplete. In such cases, the first major audit, tax inspection, or internal audit invariably boils down to the same question: “Where is the proof that the customer accepts the e-invoice, and under exactly what conditions?”

The e-invoice declaration provides an answer to this question, but it is only audit-proof if it is not a “downloaded template” but rather a document linked to the company’s processes and supporting evidence.

What is an e-invoice declaration, and why is it requested during an audit?

An e-invoice declaration (declaration of acceptance, agreement, e-invoice consent) is a written document in which the buyer (or both parties) state that:

• accept electronic invoices (not paper ones),

• via a specified delivery channel and in a specified format,

• and clarify the rules governing delivery, access, acknowledgment, archiving, and communication.

In an audit, this statement is critical because the “electronic nature” of an invoice is not merely a matter of file format. EU VAT regulations (e.g., Directive 2006/112/EC) require that e-invoices also ensure the authenticity of the origin, the integrity of the data content, and legibility, and verification of these must typically be supported by process controls and evidence (not just “we believe it has arrived”). Source: VAT Directive 2006/112/EC (EUR-Lex).

What does an “audit-compliant” e-invoice statement mean?

A statement is considered audit-ready if it provides clear, verifiable answers to two questions:

1. What does the agreement cover? (Who, what, how, starting when?)

2. How do you prove it after the fact? (Who signed it, when did it take effect, which version was in force, how were changes handled, and where is the delivery/access trail?)

An important point to note: the statement is not a standalone PDF, but rather one element of the “chain of custody.” This works the same way in many other fields, such as with service providers handling sensitive data. If you look at the guidelines and processes of a multidisciplinary psychiatric practice, you’ll see that the terms, communication protocols, and administrative frameworks are clearly documented. The same logic applies to e-invoicing: anything that isn’t precisely recorded and managed in a traceable manner is a weak point in disputes and audits.

Required content elements: “minimum” and “audit plus”

Together, the following elements constitute the standard that most financial, legal, and IT audits now consider “best practice.”

Note: The specific legal wording depends on the industry and the contractual model. The table above is not intended as legal advice, but rather as an audit-oriented checklist to identify potential gaps.

The most common mistakes that cause the declaration to be rejected

The text is too general; there aren't enough specifics.

If the statement simply says that “the buyer accepts e-invoices” but does not specify the delivery channel, the recipient, or confirmation of delivery, it will be insufficient in the event of a dispute or audit.

No versioning and no version control

It’s easy to pull up the “most recent” document, but during an audit, they ask: what was in effect at the time that particular invoice was issued and delivered?

There is no proof of delivery, only "we sent it by email"

When email is the channel, the following questions typically arise during an audit:

• Who exactly received it?

• Can delivery—or at least transfer via the system—be verified?

• What happens in the event of a bounce?

The statement is not linked to the master data

A common mistake is that the email address or EDI ID listed in the declaration does not match the one stored in the ERP/CRM system. During an audit, this quickly gives the impression of a “lack of control.”

What does the structure of an audit-ready statement look like (recommended structure)

The following structure works well for both SMEs and medium-sized companies because it is concise yet verifiable.

• 1. Introduction and Definitions: What is considered an e-invoice under this agreement?

• 2. Identification of the parties: identification numbers, partner code (if applicable), business location (if relevant).

• 3. Delivery and channel: details regarding portal/EDI/PEPPOL/email.

• 4. Format and technical requirements: format, version, character set, and handling of attachments.

• 5. Delivery and dispute resolution rules: when delivery is considered complete, the timeframe for the recipient to report an error, and the procedure for resending.

• 6. Change Management: contact persons, addresses, ID numbers, and deadlines.

• 7. Validity, Termination, and Revocation: How long it remains valid and how to terminate it.

• 8. Signatures and Representation: signatories, date, company stamp (if applicable).

• Attachment(s): technical specifications or reference (versioned), sample e-invoice.

Sample phrasing that "holds up well" during an audit

The following are sample clauses that should be finalized with a lawyer, but they provide important guidance from an audit perspective.

Channel and delivery

“The parties agree that invoices will be transmitted electronically via the [CHANNEL] channel. Delivery shall be deemed complete upon the recording of the system-side transmission/download confirmation, which the issuer shall retain as a logged event.”

Change Management

“The buyer agrees to notify the issuer in writing of any changes to delivery details (contact person, email address, EDI/PEPPOL identifier) within [X] business days at the latest. The change will take effect upon confirmation by the issuer.”

Format

“The buyer agrees to receive invoices in [FORMAT] format. The technical specifications are attached as Annex [Y] to this statement, version: [v1.2].”

The document alone isn't enough: what process controls are needed to support it?

Auditability isn't just a matter of paperwork. A statement is only as strong as the related processes that can be audited.

1) Partner onboarding and master data management

It is a good idea to integrate the e-invoice declaration into the onboarding process:

• Verification of partner information (tax ID, name, address, business location)

• Recording of delivery channels and identifiers

• Recording the status of a declaration in the system (signed, valid, expired, revoked)

If you’re planning to implement e-invoicing, it’s a good idea to get this part sorted out right at the start of the project. Syneo’s guide, “How to Implement Electronic Invoicing,” can serve as a good starting point.

2) Access Management and Logging

A common question during an audit: “Who was able to change the channel or the address?”

The following controls are typically relevant here:

• role-based access control (RBAC)

• multi-factor authentication (MFA) for admin and financial users

• Change log (who, what, when)

Related topic: E-invoice login: access management and minimum security requirements.

3) Proof of delivery

Depending on whether you use a portal, EDI, or email, the proof will differ:

• portal: download events, login logs, notification logs

• EDI/PEPPOL: delivery confirmations, message identifiers, status codes

• email: message ID, delivery log, bounce handling, resend process

The key point is to have an "invoice status history" (issued, transferred, delivered, failed, resent) that can be exported later.

4) Archiving and Retrievability

During an audit of e-invoice archiving, auditors don’t just check whether the records “have been retained for 8 years,” but also whether:

• Can an account number, partner, or date be looked up?

• Can the integrity be verified (e.g., via a hash, timestamp, or controlled system process)?

• Is there a backup and recovery plan?

For practical review: E-invoice 2026: checklist for issuance and archiving.

Digital signature and timestamp: Are they required in the declaration?

Many companies here are uncertain. The eIDAS Regulation governs trust services (such as qualified electronic signatures and time stamps) and may have legal effect in certain situations. Source: eIDAS Regulation (EU) No 910/2014 (EUR-Lex).

In practice:

• If you want to strengthen the chain of evidence (especially for email delivery), a digital signature or timestamp can be useful.

• In many cases, however, the legal requirements can also be met through auditable process controls (logging, integrity protection, access management).

You can find detailed criteria for making this decision in this Syneo article: Digital signatures for electronic invoices: Will they be required in 2026?

“Audit package”: What else should you save besides the tax return so you don’t have to scramble to gather everything at the last minute?

If you want to keep things simple, consider creating a folder or system directory where, for each partner (or group of partners), you have:

• the current e-invoice declaration (revised)

• the version of the relevant technical annex (or a versioned reference to it)

• Proof of delivery channel configuration (preferably an export or log file rather than a screenshot)

• 1–2 sample invoices with transaction history (issuance, transfer, delivery, archiving)

• change management trail (if there were changes)

This works because the goal of an audit isn’t to “tell the whole story,” but to demonstrate in 10–15 minutes that the process is under control and the evidence adds up.

When is it worth bringing in outside help?

Generally, when:

• You have multiple channels at once (portal + EDI + email)

• ERP/CRM/invoicing integration involves multiple systems, and there is disagreement over where the "single source of truth" lies

• NIS2/ISO 27001-type audits are also on the agenda, and issues related to logging, access rights, and backups must be coordinated

• We need to quickly achieve audit-ready status despite existing issues (chaotic master data, missing logs)

In such situations, Syneo typically assists with assessments, process and control design, as well as integration and security implementation, ensuring that both the statement and the underlying system processes “tell a coherent story.”