What does GoBD-compliant actually mean for invoice archives?

Revisionssicherheit is not a German statute. It is a professional term from VOI and IDW RS FAIT 3 that describes a whole system (technology plus filing process plus procedural documentation) satisfying the statutory framework of AO §146, §147, HGB §257 and the GoBD. The statutorily binding requirement is immutability (AO §146(4), GoBD Rn. 58 ff.), and the GoBD is explicitly technology-neutral about its technical realisation: hardware (WORM), software (locks, versioning, logging) and organisational measures rank equally, and combinations are allowed. A qualified electronic timestamp under eIDAS Art. 42 is a recognised technical realisation because it carries the statutory presumption of data integrity under eIDAS Art. 41(2). Neither a signature nor a timestamp makes an archive revisionssicher on its own -- without the accompanying procedural documentation and orderly filing process, the GoBD is not satisfied.

Does a digital signature really replace a WORM archive?

It is not the signature that replaces the WORM archive but the qualified electronic timestamp that delivers the alternative, GoBD-recognised technology-neutral answer to the immutability requirement. The timestamp binds the state of the document to a moment attested by a Qualified Trust Service Provider and carries the statutory evidentiary presumption of data integrity under eIDAS Art. 41(2). The AdES signature CodeB ships by default with a self-signed CA additionally provides tamper-evidence but is not a third-party-attested signer identity. The other GoBD properties -- completeness, order, timeliness, machine processability -- remain your responsibility via procedural documentation and filing process. No archive becomes revisionssicher without these, regardless of the cryptography used.

What is the difference between QES, AdES and PAdES?

EU Regulation 910/2014 (eIDAS) defines three signature classes. A simple electronic signature is essentially any electronic acknowledgement, including a scanned handwritten mark. An Advanced Electronic Signature (AdES, Art. 3(11)) is uniquely linked to the signatory, under their sole control, and detects later changes. A Qualified Electronic Signature (QES, Art. 3(12)) is an AdES based additionally on a qualified certificate from a QTSP and a Qualified Signature Creation Device (QSCD, typically a hardware HSM or smartcard). QES has the legal equivalence of a handwritten signature under Art. 25(2). PAdES is the PDF signature format (ETSI EN 319 142-1) with four conformance levels B-B, B-T, B-LT and B-LTA. For invoices, AdES plus a qualified timestamp is almost always sufficient because German tax law does not mandate QES for invoices.

Does the German tax authority require a qualified signature on invoices?

No. Since the German Steuervereinfachungsgesetz of 2011, a qualified electronic signature is no longer required for electronic invoices under UStG Section 14(3). Sufficient is an internal control procedure that establishes a reliable audit trail between invoice and delivery. QES remains a recognised but not exclusive method. AdES plus qualified timestamp is now considered best practice because it demonstrates GoBD immutability cryptographically without the QSCD-per-signature cost.

How does CodeB compare to classic WORM solutions cost-wise?

Classic WORM storage for GoBD archives sits in the several-thousand-euro range for the appliance plus ongoing maintenance. On-premise systems add hardware refresh cycles; cloud archives add per-user or per-terabyte monthly subscriptions. The CodeB signature and timestamp service bills per signature or timestamp, or as a flat allotment for small volumes. The qualified timestamp itself is purchased from an external QTSP (e.g. Sectigo, DigiCert) in the low single-digit cent range per timestamp; the signature itself costs nothing beyond the base software licence. Combined, this is a fraction of a WORM appliance for a mid-sized company.

What are the three signing paths CodeB provides?

(1) API signing: The Cloud Signature Consortium v2 endpoint /csc/v2/signatures/signHash signs a SHA-256 hash of an invoice with an OIDC-authenticated user certificate. Ideal for accounting software, ERP integrations and automated invoice output. (2) Personal EU Wallet signing: The invoice issuer scans a QR code, confirms in their European Digital Identity Wallet (EUDI wallet on their smartphone), and receives back a signed PDF with a PAdES-B-LT signature. Ideal for freelancers, tradespeople and small self-employed issuers signing as natural persons. (3) Business Wallet signing: An authorised employee or an automated batch signs on behalf of the company through a Business Wallet instance under the CSC v2 Remote Signature Service Protocol. With audit trail of who signed what when. Ideal for accounting teams handling several hundred invoices per month.

Where is the qualified timestamp obtained?

A qualified timestamp under eIDAS Art. 42 is issued by a Qualified Trust Service Provider (QTSP) on the EU List of Trusted Lists (LOTL). CodeB defaults to Sectigo (URL configurable via the registry value HKLM\SOFTWARE\CodeB\TSAURL). Customers with their own QTSP relationships can point at a different endpoint; the signature module accepts any RFC 3161-compliant TSA server. Malta-based customers can attach to the Maltese QTSP Gattaca.

Can CodeB be deployed on-premise?

Yes. CodeB Sovereign Communications runs as an on-premise IIS deployment with no cloud dependency other than the timestamp lookup at the QTSP. For regulated industries (healthcare, legal, accounting) on-premise is often mandatory. Alternatively, Aloaha Limited operates the software as a managed service from Malta. Either operating mode produces identically signed PDFs; the legal outcome of the signature is unaffected.

How long must a signed invoice be retained?

Ten years. AO Section 147(3) mandates ten-year retention for booking documents including electronic invoices. The period begins at the end of the calendar year in which the invoice was issued. Signature and timestamp must remain verifiable across that period, which is why PAdES-B-LT (long-term validation, i.e. embedded OCSP and CRL responses) is the practical target for invoice archives -- more than PAdES-B-T alone. For extra-long retention or certificate expiry during the retention period, PAdES-B-LTA with periodic archive timestamps is the answer.

CodeB Sovereign Communications is produced by Aloaha Limited in Malta -- an EU member state with an English-language legal system, GDPR applicability, eIDAS conformance and a LOTL-listed national trust list. An invoice signed and timestamped here is therefore a trust service under eIDAS Art. 25 across Germany and the EU. Software and trust services from non-EU jurisdictions (particularly US providers) bring CLOUD Act and Schrems II risks that many German companies actively avoid when handling sensitive invoice data.

Qualified timestamp · GoBD immutability · Malta

Qualified timestamp as a building block for GoBD-compliant retention.

GoBD requires immutability — and it is technology-neutral about how you deliver it. A qualified electronic timestamp from an EU QTSP carries the statutory presumption of time accuracy and data integrity under eIDAS Art. 41(2). That is the load-bearing legal component. CodeB Sovereign Communications from Malta puts one on every signed invoice through three signing paths: API, personal European Digital Identity Wallet, or Business Wallet.

Three signing paths What we deliver Legal basis Deutsch

00 · Precise attribution

What CodeB delivers — and what it does not.

To avoid confusion: “revisionssicher” is not a statutory category. It is a professional term from Germany's VOI (Verband Organisations- und Informationssysteme, originally 10 principles) and IDW RS FAIT 3. It describes a whole system that satisfies the statutory framework: AO §146, §147; HGB §257; and the GoBD (BMF letter 28.11.2019 as amended by BMF letters of 11.03.2024 and 14.07.2025). A timestamp or a signature by itself is not a system and therefore does not make an archive “revisionssicher” on its own.

Component	Role	What it delivers legally
Qualified RFC 3161 timestamp	CodeB provides as a proxy to the QTSP	Load-bearing legal component. eIDAS Art. 41(2) grants the statutory presumption of accuracy of the date and time and integrity of the data linked with it. Only a qualified timestamp from a LOTL-listed QTSP carries this presumption.
Advanced Electronic Signature (AdES) on a self-signed tenant CA	CodeB provides today by default	Technical tamper-evidence. eIDAS Art. 3(11): detects later changes. Because the issuing CA is Aloaha-controlled, signer authenticity is only as trusted as our CA — no third-party, QTSP-attested identity.
Qualified Electronic Signature (QES)	Available optionally via the wallet paths; not the default on the API path	eIDAS Art. 25(2): legal equivalence to a handwritten signature. For invoices under UStG §14(3), not required since 2011.
Procedural documentation + orderly filing	Your responsibility, not ours	GoBD Rn. 151–155 — without this documentation no archive is revisionssicher, regardless of the technology.

The core of the message. What you buy from CodeB is the cryptographic half of a revisionssicher archive — qualified timestamp + tamper-evidence. The other half — procedural documentation, orderly filing, access control — sits with you. The qualified timestamp is the one component with a statutory evidentiary presumption (eIDAS Art. 41(2)). The self-signed AdES is complementary tamper-evidence without a third-party authority.

01 · Foundation

What does “GoBD-compliant” actually require?

Revisionssicherheit is not a German statute. It comes from VOI (Verband Organisations- und Informationssysteme) and today is captured in IDW RS FAIT 3. The statutorily relevant provisions are AO §146 (immutability), §147 (retention), HGB §257 and the GoBD (BMF letter 28.11.2019 as amended by BMF letters of 11.03.2024 and 14.07.2025). Five properties derive from GoBD:

Property	Meaning	Classically satisfied by	Signature-based satisfied by
Completeness	All retention-mandated invoices are recorded.	Filing process + control	Filing process + control (unchanged)
Correctness	Booking matches invoice.	Internal control procedure	Internal control procedure (unchanged)
Timeliness	Invoice is recorded promptly.	Filing process	Timestamp records the signing moment
Order	Invoice is findable and machine-processable.	Archive indexing	Indexing + PDF/A-3 with structured XML payload
Immutability	Invoice cannot be altered undetectably after filing.	WORM hardware, blockchain, or audit-monitored database	Cryptographic signature + qualified timestamp

The core idea — and a precision point. The GoBD is technology-neutral about immutability: per the BMF letter it can be delivered “in hardware, in software, or organisationally” — combinations are allowed. WORM hardware is one recognised path. A qualified electronic timestamp plus tamper-evidence is another. What makes the qualified timestamp special is its statutory evidentiary presumption under eIDAS Art. 41(2): accuracy of the date and time, and integrity of the data linked with it, are presumed. Neither a WORM appliance nor a self-signed signature carries this presumption.

01a · The load-bearing pillar

The qualified timestamp — and why it carries the legal weight.

The central legal building block of our offering is the qualified electronic timestamp under eIDAS Art. 42, issued by a Qualified Trust Service Provider (QTSP) on the EU List of Trusted Lists (LOTL). CodeB proxies the QTSP call, defaulting to Sectigo. The QTSP is the trust anchor — not CodeB.

eIDAS Art. 41(2) states: “A qualified electronic time stamp shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound.” This presumption is evidentiary in civil proceedings (analogous to §371a ZPO in Germany) and is accepted by tax auditors.

What about the signature in front of it? The AdES signature we ship by default uses an Aloaha-controlled CA certificate and therefore provides only tamper-evidence, not third-party-attested signer identity. For GoBD immutability that is enough, because the qualified timestamp attests the data's integrity. For formal signer attribution (e.g. in an authorship dispute), the stronger choice is a Qualified Electronic Signature (QES) with a qualified certificate — not, however, required for invoices by UStG §14(3).

In one line. The qualified timestamp carries the legal weight. The self-signed AdES is complementary cryptography without third-party-attested signer identity. For maximum legal certainty, combine the qualified timestamp with a QES from a QTSP-backed wallet.

02 · Three paths

Three signing paths at CodeB.

The right path depends on invoice volume and user profile. All three produce a PAdES-signed PDF with a qualified timestamp and long-term validation data (PAdES-B-LT), verifiable across the mandatory ten-year retention window.

1. Sign via API

The Cloud Signature Consortium v2 endpoint /csc/v2/signatures/signHash signs a SHA-256 hash of an invoice with an OIDC-authenticated user certificate. Ideal for accounting software, ERP integrations and automated invoice output. Curl, Node.js, C#, PHP samples in the HOWTO.

HOWTO: sign via API →

Preview

2. Sign via personal EU Wallet

The invoice issuer scans a QR code, confirms in their European Digital Identity Wallet (EUDI wallet app on their phone), and receives back a signed PDF with PAdES signature. Ideal for freelancers, tradespeople and small self-employed issuers signing as natural persons.

HOWTO: sign via wallet →

Preview

3. Sign via Business Wallet

An authorised employee or an automated batch signs on behalf of the company through a Business Wallet instance under CSC v2 Remote Signature Service Protocol. With audit trail of who signed what when. Ideal for accounting teams handling several hundred invoices per month.

HOWTO: Business Wallet →

Preview paths are working; wallet integrations are in pilot with selected partners. The API path is production-available and documented at /csc-v2-api.

03 · Legal

Legal basis — short and precise.

The relevant provisions and what they actually require:

Provision	Requires
AO §147(3)	Ten-year retention for invoices and booking documents, counted from the end of the year of issue.
AO §146(4)	Bookings and other required records may not be modified in a way that leaves the original entry undetectable.
HGB §257	Commercial books, invoices and booking documents must be retained for ten years and rendered legible during that time.
UStG §14(3)	VAT-relevant invoices may be transmitted electronically; authenticity of origin and integrity of content must be ensured — via internal control procedure, QES or EDI.
BMF letter 28.11.2019 (GoBD)	Five-property canon: completeness, correctness, timeliness, order, immutability.
eIDAS Art. 3(11)	Advanced Electronic Signature: uniquely linked to the signatory, under sole control, detects later changes.
eIDAS Art. 42	Qualified electronic timestamp: issued by a QTSP listed on the LOTL.
ETSI EN 319 142-1	PAdES baseline signatures: B-B (baseline), B-T (with timestamp), B-LT (long-term validation), B-LTA (archival).

Not legal advice. The above summarises the most relevant provisions and does not replace tax or legal advice. For binding interpretation in your specific case, consult your tax advisor or the relevant tax office.

04 · Cost

Cost comparison: WORM appliance vs. signature-based archive.

An illustrative comparison for a mid-sized company with roughly 500 inbound and outbound invoices per month, ten-year retention:

Line item	WORM archive (classic)	Signature-based (CodeB)
Acquisition	Hardware WORM 5,000–15,000 EUR, or cloud archive setup	One-off software licence, or managed service
Running cost	15–25% maintenance p.a., or monthly cloud subscription per user	Signature volume ∼ cents per signature; qualified timestamp ∼ cents each
Storage	Proprietary	File system, your choice of location, your backup
10-year migration	Hardware refresh + data migration required	PDF/A stays PDF/A; no migration needed
Vendor lock-in	Usually strong: format, API, certification	Open standards: PAdES, RFC 3161, CSC v2
Cloud sovereignty	Often US-cloud (CLOUD Act, Schrems II)	On-premise or Malta-managed — EU law

Savings for an SME are typically in the four-digit range per year, plus a marked reduction in IT complexity. For smaller businesses under 100 invoices per month, the difference is even more pronounced.

05 · Why CodeB

Why CodeB from Malta.

Four points that German mid-market operators find here and rarely in US-hosted cloud-only offerings:

EU sovereignty. Aloaha Limited is based in Malta — an EU member state with an English-language legal system, GDPR applicability and a LOTL-listed national trust list. No CLOUD Act reach, no Schrems II constructs.
On-premise option. The entire signature infrastructure runs on your own IIS. The only external dependency is the timestamp lookup at the QTSP — configurable to the QTSP of your choice.
Open standards. The Cloud Signature Consortium API v2 is an ETSI/CEN-based vendor-neutral API. PAdES is ISO 32000-2. RFC 3161 is an IETF standard. No vendor lock-in.
Ready for the European Digital Identity Wallet. The signature infrastructure integrates with OIDC + OID4VP so signatories can use their personal or Business Wallet as signing identity — the incoming EU regulatory shape of digital identity.

Make invoices immutable at a fraction of the WORM cost.

Try the signature API with a sample call, or request a Malta-managed offer.

HOWTO: API signing CSC v2 API reference

Related: Digital Signatures Cookbook · E-Invoicing SDK · CSC v2 API · TSA Server · OCSP Responder · EU ID Wallet Software Malta · Deutsch