Why I'm building a second BuchhaltGenie

TL;DR

BuchhaltGenie works today for businesses on cash-basis accounting. Anyone who has to file a balance sheet has had to leave. For those businesses I am building BuchhaltGenie Doppik, a separate product with a shared login. The launch is planned for 1 December. The sign-off by an independent tax adviser is still open.

Minus five, and no error

Friday, 9 October, 22:45. I start a session for BuchhaltGenie Doppik. One item on the plan is a rule for invoices. Corrections must not push an invoice's net amount below zero.

Every SQL change gets two review agents. One checks the accounting, one checks security. The accounting review plays through a sequence hardly anyone would ever type.

An invoice is posted, net amount 10. A correction of plus 10 is confirmed. A second correction of minus 15 is confirmed and posted. Then the first correction is reopened.

The invoice's net amount now stands at minus 5. No error message, no abort, nothing.

The cause is a single condition. The trigger that checks the lower bound skips drafts. And reopening turns the confirmed correction back into a draft. So the rule was there, it had just missed a second path.

At 23:15 the fix is on the branch, commit 8087ba3. Reopening now checks the same lower bound. At 23:33 it is on main.

That night shows how strict double-entry bookkeeping has to be. A state like that must never come into being.

Balance-sheet filers had to leave

BuchhaltGenie is built for cash-basis accounting and for small businesses under the VAT exemption. Invoices, VAT, bank import. For many small businesses that is enough.

Found a GmbH, though, and you have to file a balance sheet. That applies to every capital company, including the flexible capital company. Sole proprietorships and partnerships reach it at the UGB threshold. That threshold is 700,000 euros in revenue in two consecutive years. Or 1 million euros in a single year. Freelance professionals working as sole proprietors never have to.

Until now that meant leaving BuchhaltGenie. Moving to another program, or handing everything to the tax adviser.

Both come at a price. Hand everything to the adviser, and you often see your numbers only once the adviser has posted them. Keep a second system, and the adviser re-enters much of it.

Doppik is meant to sit right in between. You keep the running books yourself, month by month. Your tax adviser gets a reconciled state and does not have to retype receipts. The annual accounts are still prepared and reviewed by the adviser.

Two products, one login

The obvious move would have been to extend the existing app. A switch for the legal form, a few more accounts. I decided against it.

Double-entry bookkeeping brings its own rules. Every entry balances exactly, debits equal credits. Nobody changes a posted entry, corrections only go through a reversal. Finished months get locked. The Doppik data model pins down twelve such invariants, each with its own database test.

I did not want those rules inside an app where most businesses never need them. So Doppik has its own repository and its own accounting database.

What you notice as a user stays shared. You will sign in to Doppik with your account from the existing BuchhaltGenie app. One account and one email, whatever the legal form. On top of that a shared vocabulary and small domain packages, for Austrian tax rules for example. The accounting data stays separate.

When a business outgrows the small app, an assistant called "Betrieb umwandeln" (convert business) is meant to handle the switch. Without you re-entering everything. That is the plan.

Only what you have seen gets posted

The product page has a sentence I mean literally: "Die KI schlägt vor, du buchst." The AI suggests, you post. Right below it: nothing is posted until you approve it.

That is anchored in the database. An import only creates a draft, never a posting. The page shows you the draft and remembers its fingerprint. That is a checksum over everything the posting writes: date, accounts, amounts, tax fields, linked receipts.

A posting only goes through with exactly that fingerprint. If the draft has changed since it was shown, the database refuses. The message then reads: "Entwurf wurde seit der Anzeige geändert, bitte neu prüfen." The draft changed since it was shown, please check again. The page reloads, and you take another look.

Whatever is posted hangs on a chain of checksums, per business and journal. Each link contains the hash of the one before. If someone changes a posted entry, the chain breaks, and the check shows the spot. The chain cannot prevent that, but it makes it visible. It only becomes airtight with an anchor outside the database, and that does not exist yet.

Two reviewers find more than one

Back to the night of 9 October. The minus five was found by the accounting review. The security review had recommended the same change for approval.

Later that night the work turns to manual postings with tax. In the first draft the same receipt can trigger tax twice. Once through the manual posting, once through an invoice. Each review catches part of it. The fix is a new rule in the database: one receipt, one tax.

Now the accounting review approves, and the security review raises a flag, with high priority. With the new rule, a test file would have rolled back its entire setup at commit. The accounting review had missed that. So in a single night, each review found what the other one missed.

Then one more finding turns up, and it comes from no review at all. On the side, an agent is extending the list of questions for the tax adviser. Along the way it hits a rule in the Austrian VAT Act. If a customer pays before the service, that is a prepayment for a business taxed on invoiced revenue. The tax then arises in the VAT return period of the payment, under § 19 (2) no. 1 lit. a UStG.

That very evening, the posting dialog had gained a "Sofort bezahlt" (paid immediately) option. Before the night is over, that option is locked before the service date for businesses taxed on invoiced revenue. Prepayments now have a flow of their own, and part of it is still open.

What I take from it: ask the domain questions early, not after the build.

What is still missing before 1 December

The launch is planned for 1 December 2026. You can join the waiting list at buchhaltgenie.at/bilanz. At first you only get in after activation or an invitation, as early access running in parallel. Your existing books stay authoritative, Doppik shows comparison figures.

The most important piece is still missing: the domain sign-off by an independent tax adviser. Without it there is no production use. That is written down as a hard limit in the product document, and it stays there.

I am collecting the questions for it in a catalogue of their own. Opening balances, reversals, tax cases like the prepayment. Whatever a machine can check, tests and two reviews check. Whatever only a person with domain knowledge can sign off stays open until that person has signed it off.

Whether 1 December holds, the next few weeks will show. I am looking forward to them. One thing is already settled: every posting stays a draft until you have seen it.