Procedural documentation
Your accountant asks you for a Verfahrensdokumentation: a description of how your filing actually works. This page describes the part of it that happens inside Vaultivo, and is written to be folded into yours. What only you can know is set out here as your question, and left open.
Version 1.0 · Effective 2026-08-29
It describes what happens to a document inside Vaultivo: in what order, at which point a person decides, and what is recorded as it goes. The same for every business, because the software does the same thing for every business.
It is not your procedural documentation. It is one block in it, and the smaller one: that document describes YOUR process, and most of your process is not something we can know. Who checks a document at your end, what happens to paper, which periods you apply. Those answers are marked here as yours, and left open.
Nor is it a certification, an attestation or an audit opinion. We hold none of those, and this paper substitutes for none of them. An attestation about software makes nobody GoBD-compliant in any case: the obligation is yours, and what it asks of you is precisely this document.
A Verfahrensdokumentation is conventionally kept in four parts. The table says what this page contributes to each, so you can see what is still missing without reading all of it.
Take the sections you need into your own version, and name the version number below alongside them. Copying is the point of a building block, not a liberty with it.
| Part | What this page contributes |
|---|---|
| General description | Little. Your business, your document kinds and your volumes are yours to state. What comes from us is the boundary: which documents pass through Vaultivo at all. |
| User documentation | The process your people work in: how a document arrives, how it is checked and released, how it is found again. Who at your end performs which step is yours to add. |
| Technical system documentation | The part concerning the archive: storage, immutability, checksums, the log. Which measures protect all of that is in the security paper alongside. |
| Operations documentation | Running the archive: access rights, logging, backup and recovery, changes to the process. Your own organisational rules go on top. |
Four parts is the usual shape, not the only one. If your accountant keeps it differently, reorder these sections; nothing in what they say changes.
What is described here is Vaultivo as an archive: everything from the moment a document reaches us to the moment it is permanently deleted. What happens in your business before that is not part of this building block and belongs in your own description.
Vaultivo keeps ten document kinds: incoming and outgoing invoices, incoming and outgoing credit notes, incoming and outgoing receipts, incoming and outgoing delivery notes, contracts, and other documents. It is not accounting software: Vaultivo does not post entries, does not prepare accounts and files nothing. A Verfahrensdokumentation describing your whole document flow will therefore have to name other systems as well.
Which of your document kinds actually sit in Vaultivo and which do not, which system holds the rest, and from what date that has been so.
A document arrives by one of three routes: an upload in the application, an attachment sent to your business’s intake address, or a transfer of your existing holding that we set up with you. Which route it came by is recorded with the document.
For arrivals by email, a per-business list of accepted senders decides. The intake address itself is a long random token, and mail from an unknown address is discarded without a reply, so that valid addresses cannot be guessed at.
The checksum is taken over the bytes as they arrive, before any processing at all. The file is then scanned for malware before anything reads it: no conversion, no text extraction, no filing. An inconclusive result is never treated as clean, and it cannot be overridden; the only way forward is to scan again. A file with a finding is quarantined and stays there until the owner explicitly releases it, which is itself logged.
Who at your business may upload, which senders you allow for the intake address, and by what route a document reaches you at all before it arrives here.
Nothing is filed automatically. Every document waits in your inbox until a person releases it. That is the step an audit asks about, and there is no way past it: no document type, no volume and no setting skips it.
Vaultivo reads what it can read and shows it as a proposal, together with whatever stayed unclear. None of it is adopted before you have confirmed or corrected it.
The proposal is a reading aid and not a decision, and that is more than a form of words: the retention period follows from the document type, so the release also settles how long the document stays. That is why it is required rather than quietly anticipated.
One limit, so the picture is right: for documents that were read cleanly and carry no warning, there is a bulk release with which one person confirms several at once. What is recorded is the release, not the field-by-field comparison. If your documentation describes an individual check, record whether and when you use the bulk release.
Who releases at your end, whether a second person countersigns, and how you notice that a document you were expecting never arrived at all.
The original is stored as it arrived and is never altered afterwards. Viewing versions and PDF conversions are produced as additional files beside it, so a readable rendition never takes the original’s place. When you download the original, it is the same file that came in.
A SHA-256 checksum is taken of every file on arrival and stored with the document. A nightly run reads stored originals again and compares them against the recorded value, longest-unchecked first, so the holding is covered continuously rather than once a year in one pass. Anything it finds appears in your own log.
An hourly copy of every archived original and its PDF rendition is written to a second, independent provider. The credential that writes it cannot delete. For your documentation, that is the point at which you can state that a loss in the primary store does not take the holding with it.
Actions on a document and privileged access are logged: who, what, on which document, and when. That covers the steps an audit asks about: the release, every change to a retention period, the placing and lifting of a legal hold, and every deletion.
Log entries cannot be changed or deleted. That is not a promise made by the application but a rule in the database itself: an update or delete against the log table is refused, wherever it comes from. This is the statement your documentation can make about the immutability of the records.
One limit, so the picture is right: when somebody at your business views their own document, no entry is created. What is logged is privileged access, not every view. So do not write into your documentation that every access is logged.
The log lasts as long as your account lasts, and nothing prunes it on a schedule. If you close your account, the archive is deleted after the period named in the Terms, its log included; a legal hold does not stop that either. Plan an export before you close, because afterwards there is nothing left to fetch.
On release, Vaultivo sets a retention date derived from the document kind and your business’s country, and names the basis for it.
For a business established in Austria: UGB § 212 · BAO § 132
It is counted from the end of the calendar year the document belongs to, not from the day of the document itself. The issue, contract, delivery or document date is what identifies that calendar year, and nothing more. This matches the way the applicable rules count.
The period is set once, at release. If we later change a rule, documents already filed are not re-dated. You can change any date by hand at any time, and every change is logged permanently with its old and new value.
The date is guidance and not a lock: Vaultivo does not stop anyone deleting before it falls due, it shows the period and records who decided what and when. The one thing that is enforced is the legal hold. It prevents deletion and permanent deletion for every role, the owner included; to get past it the owner has to lift it explicitly, and both placing and lifting require a reason and appear in the log.
Which periods you apply where they differ from the one proposed, who may change them, and in what circumstances a legal hold is placed at your end.
A business has four roles. What a role may do is fixed, not assembled from individual permissions. The table names the steps a Verfahrensdokumentation asks about.
| Role | May |
|---|---|
| Owner | Everything: release, change the retention date, place and lift a legal hold, delete and permanently delete, request exports, read the log. |
| Employee | Upload, release, delete and restore, request exports. No change to the retention date, no legal hold, no permanent deletion of an archive record. |
| Accountant | Read, search, download, request exports, read the log. No release and no change. |
| Read only | Read, search, download. Nothing else. |
Our system administration can sign in as a user of a business for support. That is time-limited and appears in that business’s own log, so it stays accountable there.
Who holds which role at your end, who assigns them, how often you review that, and what happens when somebody leaves.
Searching is done through one field for the whole archive: number, counterparty, amount, period, filename, and the text read out of the document. The search is tuned for German, so “Rechnungen” also finds “Rechnung”, and it is insensitive to accents, so “Muller” also finds “Müller GmbH”.
The whole archive can be exported in two formats. One is a ZIP holding the original files, a per-document list carrying the checksum, retention date and hold status, and an accounting list. The other is an archival package in BagIt with PREMIS metadata: the same files and lists, plus per document the events of arrival, checksum calculation, virus check, release, checksum verification and deletion. The package is readable by any archival system; we hold no certification against either standard.
One detail that counts in an audit: in the archival package a legal hold appears as a restriction on deletion, and a retention date does not. That is deliberate. The hold is enforced and the date is not, and a package presenting both alike would assert an enforcement that does not exist.
By what features you order your documents, who may request an export, and to whom you hand it in the event of an audit.
Deletion happens in two steps. The first is reversible: the document disappears from lists and from exports, the file and the details remain, and it can be restored. The second is permanent deletion. Only the owner can trigger it, and it cannot be undone.
Permanent deletion goes through a page of its own, not a dialog in passing. That page names the document with its filename, number, kind, counterparty, date, retention date and hold status, lists what is destroyed and what remains, and requires a separate tick. A retention date in the future does not stop it; a legal hold does.
What remains is evidence. The record persists as a stub carrying its identifier, filename, size, checksum, arrival date, the retention date as it stood at deletion, and a note of who deleted it and when; the log keeps the event in any case. For your documentation that means a gap in the holding can be explained rather than merely observed.
The file itself is removed from the primary store together with every one of its versions. The copy at the second provider does not vanish at the same moment: it sits there under a seven-day object lock and is removed by a separate daily run. So reckon on at least seven days before the last copy is gone.
Who decides a permanent deletion at your end, what that decision is based on, and how you record it.
When what is described here changes, this page changes and the version number goes up. The order is that way round: the page follows the software, never the reverse.
When something changes at your end, record it yourself. A Verfahrensdokumentation has to stay traceable across the whole retention period, superseded versions included. Vaultivo logs changes to retention periods, roles and legal holds; changes to your organisation are not something it can see.
The questions marked above are yours. Answer them in your own words and in your own document: a building block carrying our answers to them would be wrong for the next business.
On top of that comes everything Vaultivo cannot see at all, and which your accountant will ask about anyway:
We are glad to answer questions on individual points. What has to be in your documentation in the end is your accountant’s call, not ours.
Three things that are better here than in a conversation where they come as a surprise.
Every statement here is tied to a source in our own documentation, and the mapping is maintained. When a step changes, this paper changes, not the other way round.
Name the version you folded in inside your own documentation. That way it can later be said which state of the process was meant.
Version 1.0 · Effective 2026-08-29