Dokumenten-
Workflow

Barcode labels and typed-in document types: slow, error-prone, licensed

Incoming documents ran through an existing DocuWare installation and a great deal of manual work: documents were scanned, physically labelled with barcodes, and document type, business partner and transaction number were typed in by hand. That is slow, error-prone and licensed.

I designed a completely new workflow on open-source components covering the full path, from three intake channels (paper scan, XML e-invoice, file drop) through automatic recognition and validation against the ERP to audit-proof storage on WORM media, extended by department-specific approval workflows.

Three channels, one run, one archive

Status: Process analysis, target architecture, tool selection and risk assessment are complete and documented as a decision paper including a process diagram. Implementation is underway.

I owned this project on my own: mapping the existing document flow, selecting and evaluating the tooling, designing the target architecture, assessing benefits and risks for each process step, and the implementation. Colleagues and departments were consulted on specific domain questions.

An explicit part of that role was naming the weaknesses of my own design rather than glossing over them. The decision paper pairs every benefit with its corresponding risk: automation in accounts payable that nobody checks any more costs more than the manual step it saves.

Separator sheets move the failure mode rather than removing it

Dropping the physical barcodes is the most noticeable gain at the scanner, but it creates a new error class: forgotten separators, duplex scans and blank pages produce incorrectly split documents. Manageable, but it has to be reflected in the operating concept and in user training.

• Benefit No more barcode labels, just separator sheets in the stack. Document type and number are recognised rather than typed, which removes the largest manual step in the current process.
• Risk A poor scan produces a plausible but wrong assignment that nobody checks. Once nobody reviews manually, a saved keystroke turns into an undetected booking error.

Every document is validated against the ERP

A plausible misclassification is worse than no classification. A poor scan can produce an automatic assignment that looks right and isn’t. Reconciliation against the ERP is precisely the countermeasure. It catches transposed digits and wrong partners before anything reaches the archive.

A new hard dependency on the ERP. The ODBC reconciliation with the ERP makes the process robust and vulnerable at the same time. If the connection fails, the entire intake backs up. That calls for a defined fallback rather than the silent assumption that the database is always available.

Idempotency of the cron run. A periodic job over a document store needs unambiguous state handling. Without it, the job processes documents twice or skips them. Neither shows up in testing with small volumes, and both certainly do in production.

Audit-proof retention does not live where the documents live

Paperless-ngx is a capture and processing system, not an audit-proof archive. The WORM store is, but only once it is defined who writes what to it, and when. That handover is the single largest open question in the current design: without a specified write-back path and formal process documentation, a GoBD compliance gap opens up that undermines the entire value of the project. This point is flagged as unresolved in the decision paper rather than papered over.

• Benefit The WORM store stays technically unchanged; audit-proof retention is already solved there. Zero licence cost, full control, every edge case can be rebuilt in-house.
• Risk No vendor support. Maintenance, updates and process knowledge rest with a small number of people. Documentation and knowledge transfer are not optional extras here; they are part of being operable at all.

A decision-ready basis instead of a gut call

• A decision-ready basis instead of a gut call. What was delivered: a documented target architecture, a complete process diagram, and a benefit-versus-risk assessment for every individual process step. Management can decide on that basis without having to go into the technology themselves.
• The largest manual step disappears. Document type, partner and transaction number are recognised rather than typed. That is the step that costs the most time and produces the most errors in the current process.
• Every document is validated against the ERP. Transposed digits and misassigned business partners surface inside the process, not later in accounting.
• Failures do not disappear silently. Ambiguous documents get an error tag and land on a visible work list; after correction they automatically re-enter the run.
• Replacing the DocuWare licences. The design needs no paid licences while keeping full in-house control over every edge case.
• Compliance risk named before the project started. The GoBD gap was identified and documented before money was spent, not afterwards by an auditor.

How I built it