Year-over-year plausibility check of statements and returns

Many small offices produce a finished statement once a year and send it out after a quick glance: the service-charge statement of a property manager, the tax return of a tax adviser, the quarterly fee statement of a doctor's practice. Errors are expensive after the fact (deadlines, objections, corrections, liability). A plausibility check puts the new statement next to the prior years and the source data, lets rules and simple statistics find the outliers, and lets an LLM explain each one in plain language. It is a second pair of eyes, not an auto-pilot. Maturity is early-adopter: the checks themselves are easy, but ready-made products for these small niches are rare.

Problem & value

• Who: property managers (Hausverwaltung, check of statements: about 7 h in the shadow analysis), tax advisers (plausibility and optimisation check: about 6 h), medical practices (KV fee statement: about 1 h). Source: gap analysis research/gaps_2026-11_shadow.md, entry ANOM-040.
• Today: the preparer or a colleague eyeballs totals, compares a few lines with last year in Excel, or relies on built-in rule checks of the software. Software checks are rule-based (formal consistency) and rarely say "heating costs per m2 are 38 % above last year without a price change".
• AI value: line-by-line comparison with history, detection of missing items (a deduction claimed every year but absent now), allocation-key errors, and explanations the reviewer can verify in minutes. Realistic time saving on the review step: 20-40 %, not more, because every flag still needs human judgement (estimate, no published benchmark).
• Why timing matters in Germany: the landlord must deliver the service-charge statement by the end of the 12th month after the period; later back-payment claims are generally excluded, and the tenant has 12 months after receipt to object [1]. A corrected statement is only reliably possible while the deadline runs, so errors must be caught before dispatch.
• Honest limits: a deviation is not an error. A price rise, a new roof or a new patient mix explains many flags; the check produces leads, not verdicts.

Variants

• Hausverwaltung / WEG and rental: service-charge statements (Betriebskostenabrechnung), annual WEG statement. Checks: cost type versus prior year, cost per m2, allocation key versus lease, consumption share of heating costs within the 50-70 % band of the HeizkostenV [2], unallocable items (e.g. administration costs, repairs) in the list, missing units.
• Steuerkanzlei: income-tax, trade-tax and VAT returns, annual financial statements. Checks: deviation from prior-year return, items that dropped out, plausibility of deductions versus documents, VAT ratio versus revenue, items likely to trigger the authority's own automated risk management [3].
• Arztpraxis: quarterly KV fee statement versus own billing records: number of cases, coding patterns, rejected services. KVs and health insurers themselves check legality and plausibility of billing [4]; a practice-side pre-check avoids surprises. Small effort (1 h), so mostly a by-product.
• Out of scope: ledger-level anomalies (ANOM-006), payroll runs (ANOM-037), forged documents (ANOM-017), KPI monitoring (ANOM-030), authority-side case selection.

How it works

1. finished statement/return (export or PDF) + prior years + source data
2. parse and normalise to a common line structure (line item, amount, unit, key)
3. rule checks (maths, sums, allocation key, mandatory items, legal bands)
4. year-over-year deltas per line and per ratio (cost per m2, revenue vs VAT, cases per quarter)
5. outlier scoring (thresholds, robust z-score, Isolation Forest if enough history)
6. LLM explanation per flag using only the supplied figures + suggested question to preparer
7. review screen: confirm / explain / correct
8. check log in the file

• Detection is deterministic: rules and statistics find and rank deviations; this keeps results reproducible and auditable.
• LLM role: read PDF statements and cover notes, map line labels across years ("Gartenpflege" = "Grünanlagenpflege"), draft the explanation and the question for the preparer. It must not compute the figures; arithmetic stays in code.
• Human-in-the-loop: the preparer or the responsible tax adviser decides on every flag before dispatch or filing. Nothing is sent or filed automatically.

Data preparation

Which data: the finished statement, 2-5 prior-year statements, the underlying ledger or booking export, invoices, meter readings, allocation keys and the contract rules (lease clauses, fee schedule).

Where it lives: property-management software (e.g. Haufe/Domus, Aareon, Immoware, Hausverwalter tools), DATEV Kanzlei-Rechnungswesen / Steuern, practice management system (PVS), plus PDFs on file shares and in the DMS.

Typical gaps: chart of accounts or cost-type names change between years, statements only as PDF, units merged or split, meter data in separate portals, missing prior years after a software or manager change, and personal data (tenants, patients, mandates) in the files.

Preparation steps: 1. Export current and prior statements in a structured form (CSV/XML) and keep the PDF as evidence. 2. Build a mapping table of line labels and cost types across years (PREP-016 for written-down rules). 3. Reconcile each statement with its ledger total before comparing (PREP-005). 4. Convert PDF-only history with document parsing (DOC-014) and spot-check 10 statements (PREP-018). 5. Pseudonymise tenant, patient and mandate names where the check does not need them (PREP-022).

Rough share of effort: about 35 percent, mostly the year-to-year mapping. See GUIDE-003.

Implementation paths

Which path for whom

• SMB - Path A: the tool must live inside DATEV or the property-management software; where the vendor offers checks, use them first; add a narrow cloud-based checker only for the gaps.
• Enterprise - Path B: housing companies and larger tax firms have the data engineers to build checks per statement type on EU-region APIs and the own data warehouse.
• Developer - Path C: open-source tabular and LLM stack on HW2 keeps confidential client data in-house.

Path A - Buy

• Built-in checks: DATEV and the tax-return programs run formal plausibility checks before transmission (rule-based). Several vendors advertise AI plausibility features, but the claims are mostly marketing; test with your own cases and ask the vendor which checks are rules and which are ML.
• Property management: the major software suites check formal consistency; a year-over-year AI view is rare. Some tenant-side tools (Nebenkosten checkers) exist, but they serve tenants, not managers.
• Choose A when: the vendor module covers your statement type and offers EU hosting and an AVV. Expect gaps; this is why the case is early-adopter.

Path B - Build on cloud APIs

• Parse statements with a document-AI service or a multimodal LLM with JSON schema output; compute deltas and rules in Python/SQL; use an EU-region LLM API for the explanation text. Orchestrate with n8n or Power Automate (AGENT-002).
• Send only line items and aggregates, not tenant or patient names. Tax advisers must satisfy the careful-selection and written-contract duties for external providers in section 62a StBerG [5].
• Choose B when: you have a few statement types, volume of hundreds per year and a developer.

Path C - Self-host

• pandas/DuckDB + scikit-learn for the checks; Docling or PaddleOCR for PDFs; a 7-30B open-weight LLM (Qwen, Mistral class) via vLLM or Ollama on one workstation GPU (HW2) for explanations.
• Choose C when: client secrecy (Steuergeheimnis, Berufsgeheimnis, medical secrecy) rules out cloud.

Path D - Custom training

Rarely worth it. Only a large housing company or an audit-like service with thousands of statements per year benefits from a model of "normal" per building or client; labels come from reviewer decisions.

State of the art (2026)

• What works today: rule and ratio checks with history, label mapping and explanation by LLM. Robust deltas (median, quantiles) beat deep models on the small samples (5 years, 50 lines) typical here.
• What is early: end-to-end products for these specific small niches, learning "normal" across many clients, and finding missed tax deductions (needs the source documents and current tax law).
• Limits and failure modes: structural breaks (new building, sale, new contract) cause floods of false flags; LLMs can invent a reason for a deviation, so explanations must cite the figures used; tax law changes each year, so rule bases need maintenance; a missing flag is not proof of correctness.

Shared resources & combinations

• Same stack (anomaly-detection + tabular-ml + llm-general): ANOM-006 (ledger level), ANOM-037 (payroll check), ANOM-030 (KPI anomalies) - one rules-and-delta engine and one review UI serve all.
• Upstream: DOC-014 and DOC-001 (parse PDFs and invoices), LANG-033 (booking suggestions give the cleaner ledger that the check compares), DOC-012 (spreading financial statements).
• Downstream: LANG-002 (cover letter or objection reply for the corrected statement), DATA-001 (ask questions of the results), KNOW-009 and PRED-048 (heating and energy questions behind the flags).
• Biggest single effect for a property manager: combine this check with DOC-001 invoice capture and LANG-002 letters; the statement then runs from invoice to dispatch with one human review.

Effort, cost & KPIs

• Path A: days to weeks if a vendor module exists; licence per user or per unit.
• Path B/C: 1-3 months for a first version covering one statement type; effort is mapping and test cases.
• KPIs: share of flags confirmed as real errors, reviewer minutes per statement, errors found before dispatch, objections and corrections after dispatch, share of deadlines met.

People & change

Involve early: management and the department lead (Hausverwaltung, tax adviser, practice owner) as process owner, preparers as end-users, IT for exports, the data owners and the DPO. Legal/compliance joins for professional-secrecy questions.

Works council: depends. The tool checks documents, not people, but flags can be traced to the preparer who made an error. If preparer names are logged, §87(1) no. 6 BetrVG may apply; §90 requires information on AI-supported work processes. Many target firms are too small to have a works council. Keep logs on statement level (GUIDE-004).

Data protection: tenants, patients (in aggregates) and taxpayers appear in the data, so an AVV (Art. 28 GDPR) and pseudonymisation are needed; a DPIA is usually not required for a pure second check but the DPO decides (GUIDE-005).

AI literacy and pilot: train preparers (Art. 4 AI Act, GUIDE-006). Pilot on last year's statements, where the true errors are known, then run in parallel for one cycle (GUIDE-008, GUIDE-009).

Typical concerns: fear of blame for found errors (present it as a safety net), alert fatigue (tune thresholds), liability (the human signs off).

Risks, regulation & compliance

• EU AI Act: minimal. Annex III has no category for plausibility checks of statements; point 5(b) concerns credit scoring of natural persons and point 4(b) worker monitoring [6]. Do not reuse the scores to rate staff or to score tenants or patients.
• GDPR: personal data in statements (yes); legal basis legitimate interest or contract, AVV with vendors, EU hosting preferred.
• Professional secrecy: tax advisers need a text-form contract with confidentiality duty and careful selection for external services (section 62a StBerG) [5]; third-country providers only with comparable protection.
• Civil and tax law: service-charge deadlines (section 556 BGB) [1], HeizkostenV bands [2], tax authorities' own risk-management systems under section 88 AO [3], KV plausibility rules (section 106d SGB V) [4].
• Mitigations: deterministic checks, explanations tied to cited figures, human sign-off, versioned rule base.

Getting started

1. Pick one statement type (e.g. the service-charge statement) and 20 past statements.
2. Build the line-label mapping and compute year-over-year deltas in a spreadsheet.
3. Add 10 rules (allocation key, heating band, missing units, items that disappeared).
4. Let an LLM explain only the top 20 flags; have a preparer rate the flags as useful or noise.
5. Decide buy versus build after the pilot; settle secrecy and data-protection points first.

Sources

1. Section 556 BGB (Betriebskostenabrechnung, 12-month deadlines) - https://www.gesetze-im-internet.de/bgb/__556.html
2. Section 7 HeizkostenV (50-70 % consumption share) - https://www.gesetze-im-internet.de/heizkostenv/__7.html
3. Section 88 AO (Untersuchungsgrundsatz, automated risk management systems) - https://www.gesetze-im-internet.de/ao_1977/__88.html
4. Section 106d SGB V (Abrechnungsprüfung, plausibility checks by KV and Krankenkassen) - https://www.gesetze-im-internet.de/sgb_5/__106d.html
5. Section 62a StBerG (use of service providers, confidentiality) - https://www.gesetze-im-internet.de/stberg/__62a.html
6. EU AI Act, Annex III (high-risk systems) - https://artificialintelligenceact.eu/annex/3/