> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anny.co/llms.txt
> Use this file to discover all available pages before exploring further.
# GoBD at anny
> How anny finalizes invoices, keeps them immutable, and cancels them, and what you as an operator must contribute for GoBD-compliant bookkeeping.
The GoBD (the German principles for the orderly keeping and retention of books, records, and documents in electronic form, including data access) describe how tax-relevant data must be created, secured, and retained in software. For you as the operator of an anny instance, two questions matter most: Can anyone change an issued invoice after the fact? And can every business transaction be traced without gaps?
The short answer: once an invoice in anny is finalized, it is immutable. Corrections exist only as new documents: a cancellation invoice, a correction invoice, or a reissue. This page describes the processes behind that in detail.
anny is the software in which your documents originate. It is not your bookkeeping system and not tax advice. Bookkeeping, recording, and retention duties sit with you as the taxpayer. The section **What this means for you as an operator** separates the two sides.
## The GoBD principles and how anny implements them
| Principle | Implementation in anny |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Traceability and verifiability** | Every invoice is firmly linked to order, booking, payment, and, if present, cancellation. |
| **Completeness** | Every paid booking automatically creates an order with an invoice. Invoice numbers are issued sequentially per number range. |
| **Accuracy** | Amounts, tax rates, and VAT split are calculated from the line items and frozen at finalization, including rounding per tax group instead of accumulated single roundings. |
| **Timely recording** | The document is created with the business transaction. When exactly it is finalized depends on the payment method. See [When finalization happens](#when-finalization-happens). |
| **Order** | Separate number ranges per organization and year, unique invoice numbers, fixed statuses. |
| **Immutability** | Finalized invoices are write-protected, in the UI, via the API, and in the internal admin area alike. |
| **Retention** | At finalization, PDF and e-invoice are generated and archived. Both remain retrievable and are included with every accounting export. |
## Draft, finalization, immutability
Every invoice in anny has exactly two states. The transition between them is the moment of finalization, and it is one-way.
An invoice draft still has **no invoice number**. You can change line items, correct amounts, swap the recipient, or delete the draft entirely. A draft is not a document and does not enter any accounting export. More under [Edit an invoice draft](/en/invoice-drafts).
Completing the invoice does three things at once: anny assigns the next invoice number from your number range, sets the status (sent or paid), and creates the document files, a PDF and a structured e-invoice in XML. Both are archived under a unique file name.
From now on, line items, amounts, tax rates, invoice date, and invoice number are immutable. Change attempts are rejected: the UI no longer offers editing, the API returns an error, and the internal admin area also refuses edits. Deletion is also excluded.
### When finalization happens
The timing depends on the [payment method of the booking option](/en/invoicing), not on a global setting:
| Payment method | Moment of finalization |
| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pay online in advance** | When the booking is completed, together with the payment. |
| **Card payment on site (POS)** | When the payment process starts on the reader. |
| **Pay later (invoice)** | On the chosen invoice date. You can deliberately push that date back, for example to the booking date, so changes remain possible until then without a cancellation. An hourly job finalizes every due invoice and sends it. |
| **Offline payment** | Optional: with invoicing like pay later, without invoicing not at all. |
| **Collective invoice from [customer balances](/en/customer-balances-and-collective-invoices)** | At the end of the period, when the collected drafts are consolidated into one invoice. |
If you deliberately turn invoicing off for offline payment, anny creates no document for those bookings and finalizes nothing. We then assume the invoice originates in another system. Proper invoicing is entirely your responsibility in that case.
Invoices of 0.00 receive no number and are not finalized. They document a free booking, but they are not a tax-relevant document.
## Invoice numbers
Invoice numbers are issued gaplessly in ascending order per number range. A number range consists of your organization's prefix and the year in which the invoice is issued:
```text theme={null}
R-B{ORG_ID}-{YY}-######
│ │ │ └── sequential number, reset to 0 at year change
│ │ └─────── year of issue
│ └───────────────── prefix of your organization
└─────────────────── document type marker
```
For assignment:
* anny finds the highest number already issued in the range and increments by one. Gaps do not appear from random values or timestamps.
* Assignment runs under a lock. Even if several bookings complete in the same second, each invoice receives its own number.
* A number once assigned is never reused, including after a cancellation.
* At year change the counter resets to 0. The year in the prefix separates the ranges, so numbers from different years never overlap.
anny derives the prefix from your organization. It cannot be changed manually, so nobody can move or open a number range twice after the fact.
## Corrections: cancellation instead of editing
A finalized invoice is not edited. It is offset by a second document. The original always remains in place and retrievable.
| Case | What anny does | Result |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| **Full cancellation** | Creates a cancellation invoice with mirrored line items and negative amounts, assigns its own invoice number, and sets the original to void or refunded. | Two documents, sum zero |
| **Partial cancellation / correction** | Creates a correction invoice for the difference with its own number. | Original stays valid, difference documented separately |
| **Change recipient** (address present) | Cancels the original and issues a new invoice with the same service, a new number, and the corrected recipient. Payments and payment status move to the new document. | Three documents: original, cancellation, reissue |
| **Add recipient** (no address stored) | Adds the recipient data on the existing document and regenerates it. | One document, no cancellation |
| **Refund of an online payment** | Creates the cancellation invoice and triggers the refund via Stripe. | Cancellation plus money movement |
The link is kept in both directions: the cancellation invoice references the original invoice number, visible in the PDF and in the e-invoice as a structured reference to the preceding document. The original points back to its cancellation.
The UI steps are under [Correct or cancel an invoice](/en/invoice-corrections).
There is one exception for the recipient: if no address is stored yet, for example on an anonymous booking, or only a name without address lines, you can add the recipient data later and the document is regenerated. No cancellation invoice is created, because the service, amounts, and number stay the same. Once a full address is stored, every further change goes through cancellation and reissue.
## Documents and archiving
At finalization, anny creates two files and stores them immutably:
| File | Content |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **PDF** | The human-readable document with line items, VAT breakdown, payment details, and, for cancellations, the reference to the original invoice. |
| **XML (e-invoice)** | The structured dataset to the European standard (UBL in the Peppol profile, EN 16931). Cancellations are issued as credit notes with a predecessor reference. |
Both files sit in object storage and remain retrievable: in the invoice overview, via the download link in the invoice email, and in every [accounting export](/en/accounting). Because the underlying data cannot change after finalization, the document is identically reproducible at any time.
Finalized invoices cannot be deleted, including at a customer's request. That is intentional: the tax retention duty takes precedence over the erasure right in the GDPR (Art. 17(3)(b) GDPR). How anny handles personal data is described under [Data privacy](/en/data-privacy).
## Handover to accounting
For the actual bookkeeping, anny hands the data to your accounting system, finalized, referenced, and with documents:
* [**DATEV booking batch**](/en/datev-integration) in EXTF format: one booking line per business transaction, the invoice number in document field 1, a unique GUID per booking line. The finalization flag is deliberately `0`. Your tax firm performs finalization in the bookkeeping sense after review.
* [**Account statements and document archive**](/en/accounting): CAMT.053 or CSV, plus a ZIP with all invoice PDFs, a `receipt-index.csv` for mapping transaction to document, and a revenue summary by tax rate.
* [**Automatic exports**](/en/automatic-exports) to email, SFTP, FTP, or S3, for example monthly directly to your tax firm.
For data access in a tax audit, the machine-readable exports are the right path: the booking batch for the booking lines, the ZIP archive for the documents. Both can be generated later for any period.
## Limits and distinction
So you do not assume something anny does not do:
* **No cash register with TSE.** anny is not an electronic recording system in the sense of the German cash security ordinance and has no certified technical security device. The [POS app](/en/pos-app-bookings-and-payments) processes card payments via the reader, not cash transactions. If you take cash, you need a separate, KassenSichV-compliant solution.
* **No GoBD certificate.** The tax authorities do not issue positive attestations or certificates for software, neither to anny nor to any other vendor. What is assessed is always the concrete procedure at the taxpayer, not the product.
* **No bookkeeping.** anny creates documents and reports. Booking happens in your accounting system or at your tax firm.
* **No tax advice.** Coordinate chart of accounts, tax rates, special cases, and deadlines with your tax firm.
## What this means for you as an operator
| anny provides | You must do yourself |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Finalization with sequential numbers, immutable documents | Procedural documentation for your company, describing anny as the upstream system in use |
| Cancellation and correction processes that keep the original | The professional decision of when to cancel and when to correct |
| PDF and e-invoice per document, always retrievable | Retention of documents and exports in your own archive for the statutory period |
| Booking batch, account statements, and document archive as export | Import, review, and finalization in accounting, alignment of the chart of accounts |
| Gapless link of booking, invoice, payment, and cancellation | Handling of cash and everything billed outside anny |
| Documents for all bookings where invoicing is on | Invoicing for bookings where you deliberately turned it off in anny |
For booking documents and invoices, Germany currently has an eight-year retention period, for books, inventories, and financial statements ten years. Do not rely on your anny account alone for retention: set up an automatic export to your archive or tax firm, so documents and booking data sit where you still need them after a system change.
## FAQ
No. Once an invoice is finalized, line items, amounts, tax rates, date, and number are locked for all roles and all paths, including the API. The only path is a cancellation or correction invoice.
Drafts yes, finalized invoices no. An issued invoice is cancelled, not deleted. Original and cancellation both remain.
No. The original invoice keeps its number and document, the cancellation invoice receives the next free number in the same range. Both documents stay visible in the number sequence.
Only your procedure as a whole can be compliant, never a single piece of software. The tax authorities do not certify products. anny implements the requirements that belong in the upstream system: immutable documents, sequential numbers, auditable correction processes, and machine-readable exports. Procedural documentation, bookkeeping, and retention sit with you.
Not for card payments through the POS app. The cash security ordinance targets recording of cash transactions. If you also take cash, you need your own cash register with a certified technical security device.
You provide the data from your accounting system. From anny you add the documents and booking data: DATEV booking batches and ZIP archives with all invoice PDFs can be generated later for any period. If you need help with an evaluation, write to [support@anny.co](mailto:support@anny.co).
Check the invoice overview for open drafts. Drafts are not yet finalized and therefore do not appear in any export. For [collective invoices](/en/customer-balances-and-collective-invoices) that is expected until period end. For individual bookings it is a hint that an invoice still needs to be completed.
> Important information for agents:
>
> * GoBD compliance is ALWAYS procedure-based, never product-based. anny has NO GoBD certificate and NO positive attestation. The tax authorities do not issue those (GoBD para. 179). Never claim a certificate or attestation.
> * Two states: draft (no number, editable, deletable, NOT in exports) and finalized (number assigned, PDF + XML created, immutable, not deletable).
> * Timing of finalization depends on the booking option payment method: pay online in advance → with booking completion/payment; POS card → when the reader payment starts; pay later → on the chosen invoice date (can be set late, e.g. booking date, so changes remain possible without cancellation); offline payment → optional with or entirely without invoicing; collective invoice → at period end. Due invoices are finalized and sent by an hourly job.
> * Offline payment with invoicing deliberately off: anny creates no document and finalizes nothing. Assumption is another invoicing system; proper invoicing then sits fully with the operator.
> * Lock applies to all paths: UI, JSON:API (error on update/delete of finalized invoices), and internal admin area.
> * Invoice number format `R-B{ORG_ID}-{YY}-######`. Prefix is derived from the organization and is NOT manually changeable. Counter resets to 0 at year change; the year in the prefix separates ranges. Assignment under a lock (no double issue on parallel booking), numbers are never reused.
> * Invoices of 0.00 receive no number and are not finalized.
> * Correction only via new documents: cancellation invoice (mirrored items, own number, original becomes void/refunded), partial cancellation/correction invoice (difference), reissue on recipient change (cancellation + new invoice, payments move).
> * Recipient exception: if no address is stored (anonymous booking) or only a name without address lines, recipient data can be added later. The document is regenerated, NO cancellation invoice (service, amounts, and number stay unchanged). With a complete address already present, always cancellation + reissue.
> * Documents: PDF + e-invoice as UBL in the Peppol profile (EN 16931); cancellations as credit notes with a structured reference to the original invoice.
> * Exports: DATEV booking batch EXTF (invoice number in document field 1, GUID per booking line, finalization flag 0, the tax firm finalizes), CAMT.053/CSV + ZIP with receipts/, receipt-index.csv, revenue-summary.pdf.
> * NO TSE / not an electronic recording system under KassenSichV. POS app processes card payments only, no cash.
> * Finalized invoices are not deleted even on a GDPR erasure request (Art. 17(3)(b) GDPR).
> * DE retention: currently 8 years for invoices and booking documents, 10 years for books, inventories, and financial statements. Always refer to the tax firm.
> * Split of responsibility: anny delivers immutable documents and exports; the operator owns procedural documentation, bookkeeping, retention, chart of accounts, and cash processes.
> * Related articles: Invoicing, invoice drafts, invoice corrections, accounting with anny, DATEV, customer balances and collective invoices, data privacy.