Can AI Prepare a GmbH Annual Financial Statement?

Yes. And I do not mean "a model can suggest a category". I mean a complete German annual close: balance sheet, profit and loss, and the tax declarations on top, produced from raw bank data by software, and identical to what a tax advisor filed.

We know because we checked it the only way that counts. We took a full GmbH annual financial statement for a first, short fiscal year, prepared by an outside tax advisor, signed and filed. Then we rebuilt the same year from the raw bank data through our own product: import, categorisation, payroll, closing entries, balance sheet, profit and loss, the statutory presentation, and the declarations. Every account balance and the result for the year came out identical, to the cent.

That is the whole claim, and it is a bigger one than the industry usually makes, because the comparison is against a finished professional deliverable rather than a benchmark we designed ourselves.

Can AI prepare a GmbH annual financial statement?

It can, and the reason most people assume otherwise is that they have only ever been shown the easy half.

Almost every AI bookkeeping demo stops at classification: a receipt goes in, a booking proposal comes out. That step has been solved to the point of boredom. The part people are actually afraid of is the year end, because a close is not a sequence of good guesses. It is a document with a legally required shape, and being nearly right is the same as being wrong.

So the question worth answering is not "how accurate is the model". It is "does the finished statement match what a professional would have filed". Ours does. And once you have that, doing your own annual close stops being a leap of faith and becomes a review task.

The industry is arriving at the same place from the other direction. Pilot announced a fully autonomous AI Accountant in February 2026, running onboarding through monthly close and producing complete financial statements. BlackLine followed in April with an agentic operating model built around making that trustworthy. The benchmark world moved too: OpenAI's GDPval, published in October 2025, dropped exam-style scoring and had professionals judge model output against real work products across 44 occupations.

That is exactly the test we ran, on the hardest deliverable in German small-business accounting. I would rather show you a matched statement than a percentage.

What Norman closes for a GmbH today

The pattern in that table is the point. There is no layer where the answer is "you will need to leave the software and do this in a spreadsheet". The close runs end to end, and the last row is a design decision rather than a gap: German record-keeping rules want a change log that can name who booked what and when, and we went through our own audit trail against that standard before we were comfortable. "The system" is not a name. A person approving a finished, correct statement is.

What it took to make the numbers match

This is the part that separates a close you can file from a demo, and it is worth being specific about, because none of it is model work.

The chart of accounts is a ceiling nobody talks about. Our default German chart for small companies offers 79 bookable accounts, drawn from a reference list of roughly a thousand. For a first-year company with barely any revenue, the advisor still reached for about two dozen codes that were not in the default set, and half a dozen with no equivalent at all: currency gains and losses, and the accounts where non-deductible expenses have to sit so the tax computation can add them back later. Any automation with a curated chart hits this. We extended the chart and made it extendable per company, which is why the replay could express the advisor's working set at all.

Derived fields turn every write into a state machine. Reverse charge, in our data model, is not a flag you can set. It is computed:

reverse_charge = derive(sale_type, supplier_country, input_vat_type)
# setting reverse_charge=true on its own is recomputed from the three inputs

That is correct behaviour and it is also the sharp edge for anything writing through an API, an agent included. Agents write fields. The domain has states. Every derived field is a rule the caller has to know and cannot see, so the tool surface has to expose the inputs rather than the conclusion. Getting this right is most of what makes automated bookkeeping survive contact with VAT law.

Rounding has a direction. The taxable base rounds down, not to the nearest cent. It is a one-line rule, invisible to any test we would have written unprompted, and a professional's filed numbers surface it immediately.

Presentation is a second implementation of the same law. When losses exceed equity, German commercial law requires the excess on the asset side rather than a negative equity figure. Our close engine does this. The publication template did not carry the same line, so one document printed inconsistently while the filing itself was correct. One rule, two renderers, and the etalon found it.

None of these were model failures. They were the ordinary, unglamorous domain work that has to exist under an AI feature before the AI feature means anything. We wrote before that accuracy percentages tell you almost nothing about a bookkeeping system. A matched annual close is the measurement I would put in their place.

Should you let software do your annual close?

If you run a GmbH or UG, the honest answer in 2026 is yes, with a review. The bookkeeping and the statement are machine work now, demonstrably so. What you keep is the last decision: you look at a finished result and approve it, or you send it to an advisor who does, which is a normal and cheap division of labour.

What has changed is where the effort goes. It used to go into producing the statement. It now goes into checking one. That is a much smaller job, and it is the reason we spent a fiscal year's worth of engineering on a single comparison instead of a marketing claim.

If you want the background on what the statement has to contain, we keep a plain guide to the GmbH annual financial statement, and a separate one on how corporate income tax is computed on top of it.

Frequently asked questions

Do I need a tax advisor for my company's annual financial statement?

For a GmbH or UG there is no legal requirement to use one. The statement has to satisfy commercial law presentation rules and feed the tax declarations correctly, and that is now automated: our own software reproduced a filed statement exactly. Most founders keep an advisor for the sign-off rather than the production, which is far less work and far less expensive than handing over the whole year.

Can I prepare a GmbH annual financial statement myself?

Yes, and with the right software you are reviewing rather than assembling. The parts that used to make this unrealistic alone, the statutory ordering, the reclassification when losses exceed equity and the tax add-backs that turn a commercial result into taxable income, are rules rather than judgement, which means software can carry them. In Norman the close runs from your bank data through to the electronic filing.

Can you hire a tax advisor only for the annual financial statement?

Yes, and it is a sensible split. You keep the bookkeeping in software through the year, and engage an advisor for review and sign-off at the year end. Our results support that split, because the year-round bookkeeping and the statement itself are the parts a machine now reproduces exactly.

Does AI replace DATEV for a GmbH?

It replaces the manual work, and the axis that matters is whether your data can leave the tool intact for whoever files. Norman produces the statement and the declarations itself and still exports cleanly, which is the comparison we drew when looking at DATEV alternatives for a GmbH. The real shift is that a machine can now be graded against a professional's finished work and match it.