Verfahrensdokumentation: from a compliance MVP to a white-label SaaS, in two milestones.

A German compliance product, built in two milestones

A Verfahrensdokumentation is the process documentation that German SMBs and their tax advisors are required to maintain under GoBD, the Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (in plain English: the German tax authority’s rules on how digital books, records, and documents must be kept and made available to auditors). GoBD is issued by the BMF (Bundesministerium der Finanzen); the version this product implements came into force on 1 April 2024 with the BMF letter of 11 March 2024. The Verfahrensdokumentation is the document that proves your business follows those rules. The document is not the point. The point is that on the day a Betriebspruefer (German tax auditor) walks in, the documentation matches what the business actually does, every change to a sensitive field has a name and a timestamp next to it (per the Unveränderbarkeit principle), and every form, attachment, and signature is part of a single coherent record. The product this case study describes ships that record as a workflow rather than a one-time PDF.

I came onto the project as a solo senior lead developer in early 2024. The client, a German process-management consultant, had a clear product vision and needed someone who could turn it into a working multi-tenant SaaS on Bubble.io. The V1 MVP shipped that year as the platform’s blue-branded admin portal serving end-client companies directly. In 2025 the same client brought me back for the V2 extension that turned the MVP into a partner-distributable white-label SaaS, with Bubble.io sub-apps that let partner agencies and collaborators offer the product to their own clients under their own brand and their own domain, a usage-based licence model, PDF Monkey, n8n for document merging, an AI integration that helps end users fill in compliance fields from plain-language answers, and the rebranded gold GoBD.ai customer surface with the audit workflow, the Aenderungs-log, and the IKS module. The V3 milestone is in progress in 2026 as the next chapter of the same engagement. The product is live at app.verfahrensdokumentation-digital.de.

The V1 brief was to ship a working MVP of a multi-tenant compliance workflow platform that German SMBs could actually use. Not a questionnaire that produced a PDF; a tenant-aware SaaS where every customer ran their own document workflow against the same shared infrastructure. The V1 surface lives in the blue VD2 admin portal: tenant setup, user and role management, per-form access scoping, email templates, language preferences, audit history. The scope split across these pieces:

1. Multi-tenant SaaS DB architecture and relation-based UI. Every customer's data isolated by tenant; within a tenant, every form, every field, every audit row tied back to the right company, the right user, and the right document version. The UI reads the schema directly; the relations between Tenant, Company, User, Form, Section, Field, Audit row are what the page-level workflows hang off.
2. AirDev Canvas framework, with WU optimisation alongside. Canvas gave the time savings on the boring layers (auth, accounts, navigation). The Workload Units optimisation pass (server-side constraints, paginated repeating groups, scheduled workflows scoped to change windows) kept the app under control when Bubble moved its pricing model from capacity to WU.
3. GoBD compliance as a structural property, with GDPR on top. GoBD's seven principles (Nachvollziehbarkeit, Vollständigkeit, Richtigkeit, zeitgerechte Buchungen, Ordnung, Unveränderbarkeit, and the §§146/146a AO data-access rules) shaped the schema, the audit log, the retention behaviour, and the export surface. GDPR sat on top: lawful basis per processing activity, data minimisation in the form design, right-to-erasure preserving the audit log integrity, processor agreement under Article 28, data-region pinning. Privacy Rules at the data type level so both compliance postures live in the database, not in a UI filter.
4. CRUD documentation forms. Six form types per Verfahrensdokumentation (Document Storage, Company Data, Tax Data, Incoming Receipts, Outgoing and Internal Receipts, Papierbelege workflows). Each form has its own data shape, its own validation, its own role-permission scope. Same CRUD machinery underneath.
5. Company-based access mechanism, built on company hierarchy. A parent company sees its children. A child sees only itself. Tax advisors and reviewers cut across the hierarchy with role-scoped permissions. The access matrix lives at the data type level via Privacy Rules; the UI just reflects what the database lets through.
6. Document download with merge-PDF. V1 used Bubble's native page-to-PDF conversion to render the document for download. A merge step combined the rendered Verfahrensdokumentation with attached source files (uploaded PDFs from the form steps) into a single deliverable file. Mechanically fine for V1; replaced in V2 with a proper PDF generation pipeline.
7. Comments with @mention for internal communication. Reviewers, owners, and advisors leave comments scoped to specific form sections. @mention pings the right user. Threaded inside the form so context never has to leave the document.
8. Critical-area identification with smart email throttling. Not every change is worth an email. Critical fields (signers, legal entities, retention policies, IT-environment metadata) trigger immediate notifications to the right roles. Non-critical edits roll up into a daily digest. The throttling logic decides at workflow time whether the user gets a per-change email, a digest entry, or nothing.

The V1 admin portal showing the Current Document Storage view: every form in the Verfahrensdokumentation listed against one document version, with per-form status badges and a single download path for the merged document.

A form expanded inline in the V1 admin portal. The data type, the related entities, and the per-row controls all read directly from the schema. The UI is a thin layer over the database.

The same form opened full-screen for deep editing inside the V1 admin portal. Canvas gave the layout shell; the editable rows, the file upload, and the role-scoped controls are product-specific.

The email-template admin in the V1 portal. One registry, every transactional message in the product driven from it, the smart throttling configured per template.

The User Rights Comparison surface in the V1 portal. Permission changes are themselves versioned and diffable, so an auditor can see exactly what access a user had at a given time, per the Nachvollziehbarkeit principle.

Bilingual by construction. Every screen, every email template, every generated document renders in English or German from the same content store. The language is a per-user preference scoped per tenant.

Per-form access management in the V1 portal. Access is scoped per form, not per app. A tenant admin can hold rights on Document Storage without ever seeing the IKS module, and vice versa.

Each tenant (an end-client company) manages its own users and roles inside the V1 portal. The Standard / Manager role choice scopes which forms and actions the new user can reach across the company hierarchy.

Per-tenant company profile in the V1 portal. Branding, billing, notification preferences all live in one place per end-client tenant, the foundation V2’s sub-apps would later wrap at the partner layer.

The V2 brief was to take the V1 MVP and turn it into a partner-distributable white-label SaaS, with the IKS module as the headline functional addition and the gold GoBD.ai customer-facing surface as the new visual identity. IKS is the Internes Kontrollsystem (Internal Control System), the companion artifact GoBD expects alongside the Verfahrensdokumentation. Where the Verfahrensdokumentation documents what the business does with its records, the IKS documents how the business controls and verifies those processes. A complete GoBD compliance posture needs both. V1 shipped the Verfahrensdokumentation administration; V2 added the IKS module so the same product serves the full compliance picture. The product topology also expanded: V1 served end-client companies directly as tenants in one shared admin portal; V2 added a partner layer above that, so a process-consulting firm or a Steuerberater (tax advisor) practice can resell the product under their own brand to their own clients, each on their own Bubble sub-app, each with their own multi-tenant pool of end-client companies underneath.

1. White-labelling via Bubble.io sub-apps, for partners. Each partner agency or reseller gets their own Bubble sub-app with their own database, their own users, their own domain, and their own brand. The partner's end clients sign up inside the partner's sub-app, not the parent app, and never see the platform vendor's brand. The editor design, the workflows, and the data type schemas are pushed from the parent app, so a product feature ships once and lands across every partner's instance. The complexity is the parent-child sync discipline, the per-partner domain DNS, the data-driven branding layer that survives parent pushes, and the per-sub-app API keys a parent push resets.
2. Partner licence model. Partners take a recurring licence to operate their own branded instance of the platform. The partner runs the day-to-day customer relationship with their own clients under their own brand; the platform vendor licenses the product, ships the upgrades, and handles the underlying infrastructure. Partner pricing is set at the licence level (not metered per end-client action), so partners can build a predictable margin into the rate they charge their own customers.
3. PDF Monkey for properly designed document generation. V1 used Bubble's native page-to-PDF for the document download. V2 replaced that with PDF Monkey, a templated PDF generation service. The output is a designed compliance document with consistent typography, page breaks, headers, footers, and table layouts that the page-to-PDF approach could not reach. The Bubble.io app sends the structured form data; PDF Monkey returns a rendered PDF.
4. n8n for merging the generated PDF with attached source files. A complete Verfahrensdokumentation download is the rendered document plus every supporting attachment uploaded against the forms. PDF Monkey gives the rendered document; n8n orchestrates the merge: it picks up the PDF Monkey output, pulls the attachments from Bubble, runs the merge, and posts the single deliverable PDF back into Bubble for download. The whole pipeline runs server-side without the user waiting on a long Bubble workflow.
5. AI integration: plain answers to compliance language. The hardest part of filling in a compliance form is the language. A small-business owner knows what they do; they do not know how to phrase it in compliance-officer-speak. The AI integration lets a user answer a simple plain-language question and writes the compliance-specific answer into the form for them. The user reviews and edits before saving; the AI is a first-draft assistant, not an autonomous filler.
6. Webhook setup for inbound and outbound events. PDF Monkey, n8n, Stripe (for usage billing), and the white-label sub-apps all communicate with the parent app through webhooks. The receiver workflows validate signatures, dispatch to the right handler based on event type, and write status rows for observability.
7. Compliance form version comparisons, on a row-and-field basis. When a form is in Korrektur Modus, every field renders as a previous-value / current-value pair with red highlighting on the change. The diff is computed per row of every repeating section, not per form as a whole, so a reviewer can accept or reject changes at the granularity they were made.
8. The Aenderungs-log audit surface. Every edit to a sensitive field across every form lands in a paginated log with the previous value, the current value, the user, and the timestamp. The log is also the substrate the right-to-erasure workflow has to preserve through GDPR-mandated deletions: rows are written with the actor identifier scrubbed but the value-change retained, so the audit trail does not become unverifiable. V1 built the schema for this; V2 built the surface that makes it useful.
9. In-app YouTube walkthroughs alongside the forms. Embedded video walkthroughs live next to the forms they explain on the customer-facing surface. A new reviewer joining a customer team can learn the workflow without a separate training call. The walkthroughs are scoped per form so the relevant context is one click away from the work itself.
10. The IKS module, the second GoBD artifact. Internes Kontrollsystem forms (IKS Firmendaten, IKS IT Umgebung, IKS Eingangsbelege, and others) added alongside the Verfahrensdokumentation forms in the customer-facing GoBD.ai surface. Same multi-tenant schema, same role-based access, new audit log surface above, new form definitions and new audit-mode workflow on top.
11. Role-based access mechanism, extended for multi-company hierarchy. V1 had role-based access for a single-company tenant. V2 extended it to the multi-company hierarchy that a holding or a multi-entity group needs: an advisor can have Audit-mode rights on every child of a parent, an Anpassen scope limited to one child, and a Korrektur scope across two. The access matrix lives at the data type via Privacy Rules joined to the hierarchy.

The V2 GoBD.ai client-facing dashboard mid-audit. The gold rebrand carries the new end-user surface; the per-partner sub-app means each partner’s clients see this dashboard at the partner’s own domain under the partner’s brand.

The same dashboard on first open in a partner’s sub-app, before any audit cycle has started. Each partner agency hosts their own client pool inside their sub-app; the parent never touches the partner’s data.

The multi-company modal inside an IKS form. A Verfahrensdokumentation for a holding or a multi-entity group links children into one document, the V2-extended hierarchy that sub-apps and tenant-level access both build on.

The client-facing dashboard partway through an audit cycle, inside a partner’s sub-app. Every state transition (Korrektur start, Anpassen accept, Genehmigt commit) is logged in the Aenderungs-log and reflected in the dashboard’s status counters.

The V2 forms inventory with the in-app YouTube walkthrough modal open. End-user onboarding inside the partner’s sub-app, so a new reviewer learns the workflow without leaving the work.

Firmendaten, the company master-data form in the V2 customer surface. Fields tied to the schema, attachments uploaded against the form, AI-assisted plain-language drafting for the long-form fields, PDF Monkey rendering for the final document.

The audit log for one form in the V2 customer surface. Every sensitive-field edit lands here with a previous-value / current-value pair, the user, and the timestamp. The rendered PDF Monkey document carries this history forward; n8n merges any attached source files into a single deliverable PDF.

Inside a flagged IKS form, every field renders as a previous-value / current-value diff per row. The red borders show what the reviewer flagged; the reviewer accepts or rejects per row, not per form.

IKS Eingangsbelege in Korrektur Modus. Every field is a proposed change against the live record, the auditor comments thread underneath, the accepted changes land in the audit log on transition.

The IT Umgebung IKS form in Audit mode. Long-form fields diff just like the structured ones; auditor comments attach per field for the next round of Korrektur.

What changed

The product is live and serving German SMBs and their tax advisors through both the direct channel and partner agencies. V1 shipped the blue-branded multi-tenant admin platform with the schema, the role-based access, and the quality-of-life features that made the workflow usable. V2 added the gold-branded GoBD.ai client-facing surface with the IKS module, the Aenderungs-log audit log, in-app walkthroughs, partner-channel Bubble.io sub-apps so process-consulting firms and Steuerberater practices can resell the product under their own brand, a PDF Monkey + n8n document pipeline, an AI integration that writes compliance language from plain-language inputs, webhook orchestration across the toolchain, and row-field-level form version comparisons. The V3 milestone is currently in development in 2026 as the next chapter of the same engagement, with me continuing as the lead developer.

The pattern of the engagement is the part I would do again. Take the MVP scope seriously enough that the schema can carry the next milestone. Carry the same product through V1, V2, and V3 as the same Bubble.io app rather than a rewrite. Let the trust compound over a long-arc client relationship rather than chasing the next short engagement.