Procedural documentation (GoBD)

The German GoBD rules require every business to keep a procedural documentation: a description of how tax-relevant data is created, processed, retained and output again.

This page is the system part of it — a description of what Octibiz provides technically. It is not legal advice and does not replace consulting your tax advisor. What your business has to decide and document itself is listed at the end of the page.

All user interfaces, automation and the AI tools work through the same interface. The safeguards below therefore apply to each of these paths alike, because they sit in the interface's write path, not in the user interface.

Documents: draft and commitment

An invoice has two states:

• Draft. Freely editable, without a document number yet. A draft can be deleted; even then it is

only marked as deleted and stays in the database.

• Issued (committed). Issuing via /api/v1/invoices/{ulid}/issue (permission

invoicing.invoice.issue) assigns the document number. From that moment on the system rejects every change to and every deletion of the invoice.

Sending by email does not change the document; it is a separate step next to the document.

Corrections never overwrite anything; they create a further document (permission invoicing.invoice.cancel):

• Cancellation via /api/v1/invoices/{ulid}/cancel: a credit note linked to the invoice is

created, and the invoice counts as cancelled afterwards. Issued or overdue invoices can be cancelled.

• Partial correction via /api/v1/invoices/{ulid}/correct: a partial credit note against the

invoice is created; the invoice itself remains.

Credit notes are only created in these two ways, never as a free-standing document.

Document numbers

Document numbers are assigned by a central numbering engine. Each document type has a number range with a configurable pattern (prefix, brand, date, running number with padding), optionally separate per brand and reset never, yearly or monthly.

In addition, the invoice number is defined as unique in the database: the same number cannot exist twice.

Logging

Every write action creates an entry in the change log. It contains:

• the affected data type and record,
• the action (create, update, delete),
• the state before and after,
• who acted — a person, the AI or an automation — with the actor's identifier,
• a request identifier that groups the entries of one request,
• the time.

Secret values are redacted in the log, among them passwords, access tokens, values stored encrypted, IBAN and BIC.

The log is read via /api/v1/audit-logs (permission platform.audit.read). The interface offers no way to change or delete an entry.

The log is stored in monthly partitions. The setting audit.retention_months decides whether old months are removed: by default it is 0, and then nothing is removed. A value greater than 0 removes whole months that lie completely before that period. The system also ships a row-based deletion rule for the log; it is switched off by default.

Retention

The statutory retention period is held in the setting dsgvo.legal_retention_years, 10 years by default. The system counts it to the end of the calendar year: the period ends on 31 December of the year that results from the document's year plus the period.

While this period is running for a customer, a GDPR erasure request does not lead to deletion. Instead, the customer and their contacts are restricted: the system hides them from all queries, but they remain complete. Only holders of the permission platform.dsgvo.access_sealed can see restricted data.

Other data types have retention rules. They are data, not hard-wired values: readable via /api/v1/dsgvo/retention-policies with platform.dsgvo.view, maintained with platform.dsgvo.manage. A daily run applies them.

Invoices and credit notes are not subject to any retention rule. The system never deletes them on its own — not even after the period has expired. An issued invoice cannot be deleted through the interface at all.

Data access for tax audits

The GoBD distinguish three kinds of access. This is how they map to Octibiz:

• Direct access (Z1): the auditor gets a user account of their own with a role that carries read

permissions only, for example invoicing.invoice.view and platform.audit.read. Roles can be composed freely (permission platform.role.manage). The system does not ship a ready-made auditor role.

• Indirect access (Z2): evaluations requested by the auditor are prepared by your staff with the

existing lists, filters and reports.

• Data carrier provision (Z3): through the exports in the next section. In addition, lists that

use the standard pagination — among them the invoice list /api/v1/invoices — can be retrieved as a CSV file, with at most 10,000 rows per request. For point-of-sale data there is also the DSFinV-K export (see below).

Export

• DATEV via /api/v1/accounting/export/file (permission accounting.export.run) in three

formats: booking batch in EXTF format, master data of the personal accounts (debtors and creditors), and a ZIP package with document images for DATEV Unternehmen online.

• Commitment flag: the setting accounting.datev.lock_bookings is 1 by default. The booking

batch therefore carries the "committed" flag, as GoBD practice expects. The value 0 is possible; agree on it with your tax advisor first.

• E-invoice as XRechnung or ZUGFeRD via /api/v1/invoices/{ulid}/e-invoice. It can only be

created after issuing. The generated file is stored and is not rewritten on later requests.

• Document PDF via /api/v1/invoices/{ulid}/pdf.
• Incoming e-invoices are read in via /api/v1/accounting/incoming-invoices/import-e-invoice.
• Point-of-sale data (DSFinV-K) via /api/v1/pos/exports (permission pos.export.manage): a ZIP

package with description file, DTD and the CSV files according to DSFinV-K 2.3, per cash register closing. Shifts that are still open are skipped and named. The generated file is frozen and not recalculated.

The export is not a booking. Bookings are made in your accounting software.

What the system does not provide

• No archived invoice PDF. An invoice PDF is generated anew from the stored, committed data on

every request. The content stays the same; if you change the document template, however, a PDF generated later looks different from the one that was sent.

• No ready-made auditor role — it is composed from read permissions when needed.
• **No export following the tax administration's description standard for invoices and booking

data** (GDPdU format with a description file). Such an export exists only for point-of-sale data (DSFinV-K, see above).

• No protection of the log at database level. The interface can neither change nor delete log

entries; anyone with direct database access can.

• No audit-proof storage on write-once media. Files are kept in the configured file storage.

What your business has to arrange itself

• Organisational instruction: who issues, cancels and exports invoices, and who gets which

permissions.

• Operations documentation: hosting, administration, who has direct database access, and

backups (see Backup & restore and Hardening & security).

• Check the periods: adapt the values of dsgvo.legal_retention_years and the retention rules

to your legal situation. audit.retention_months should not be shorter than the retention of your documents.

• Copies sent: if the document image matters, additionally keep the PDF that was sent.
• Disposal after the period: the system never deletes invoices on its own; disposal is your

decision.

• Auditor access: create a role with read permissions, limit the account in time and lock it

after the audit.

• Agree with your tax advisor: commitment flag, chart of accounts and default accounts.
• Document upstream systems: point of sale, time tracking, web shop and their interfaces.
• Maintain this documentation: it is subject to retention itself; record changes with a date.

admin.procedural-documentation · Available from version 0.6.22