Der Pre-Audit-Check: Den Verifier über Ihre Zahlen laufen lassen, bevor es die Prüfer tun

Es macht einen echten Unterschied, ob ein Prüfer einen Fehler in Ihren Zahlen findet oder ob Sie ihn selbst zuerst finden. Das eine ist eine Randnotiz in einem Planungsgespräch. Das andere ist eine verlängerte Fieldwork, eine Nachfrage, und ein Controller, der im Nachhinein erklären muss, warum die Bilanz nicht aufgegangen ist. Die Prüfungsvorbereitung, die die meisten Teams leisten, dreht sich um die Nachweiskette hinter jeder Zahl. Dies hier ist der engere, mechanischere Begleiter dazu: dieselben Prüfungen, die das Modell ohnehin bei jedem Export erzwingt, bewusst als Gesundheitscheck durchzuführen – in den Wochen, bevor ein Prüfer die Datei überhaupt öffnet.

Was tatsächlich geprüft wird

Der Verifier von Rexfin prüft nicht nur, ob eine Zahl existiert – er prüft, ob die Bilanzidentitäten, die gelten müssen, tatsächlich gelten. Die Bilanzidentität (Aktiva gleich Passiva plus Eigenkapital) und die Kapitalflussidentität (operativer, Investitions- und Finanzierungs-Cashflow plus Wechselkurseffekt ergeben zusammen die tatsächliche Veränderung der liquiden Mittel) sind die beiden, von denen jeder ohnehin weiß, dass sie stimmen müssen. Weniger sichtbar ist, dass Rexfin mittlerweile drei weitere parallel dazu laufen lässt: eine Prüfung der Ergebniskonsistenz, eine Prüfung der operativen Zwischensumme und eine Prüfung der Steuerkonsistenz. Keine davon ist neue Mathematik – es sind Identitäten, die jeder Bilanzbuchhalter ohnehin erwartet –, aber sie mechanisch für jede relevante Periode durchzuführen, statt darauf zu vertrauen, dass sie gelten, weil das Workbook plausibel aussieht, ist das, was aus „sollte aufgehen” ein „geprüft” macht.

Bevor diese Rechnung überhaupt läuft, muss jeder Operand verankert sein: zurückverfolgt bis zur exakten Quell-PDF-Seite, von der er stammt – nicht bloß als richtig angenommen, weil die Zahl plausibel wirkt. Ein Pre-Audit-Check stellt im Grunde dieselbe Frage, die ein Prüfer während der Fieldwork stellen wird – lässt sich diese Zahl bis zu etwas Realem zurückverfolgen –, nur Wochen früher und ohne dass jemand auf die Antwort wartet.

Harter Fehlschlag oder nur Hinweis – und warum der Unterschied hier zählt

Nicht jeder Fehlschlag wird gleich behandelt, und genau dieser Unterschied macht einen Pre-Audit-Lauf nützlich statt bloß laut. Stammen alle Operanden einer fehlgeschlagenen Identität aus einer tatsächlichen, eingereichten Periode, ist der Fehlschlag real und blockiert den Export vollständig – kein Board-Pack und keine Aufstellung verlässt das System mit einer Bilanz, die nicht aufgeht. Ist auch nur ein Operand ein Forecast- oder Modellwert, ist derselbe Fehlschlag nur ein Hinweis, denn eine Prognose darf vorläufig sein, ein testierter Ist-Wert nicht. Führt man die Prüfung selbst vor der Fieldwork durch, sieht man diesen Unterschied frühzeitig: Ein harter Fehlschlag bei einer abgeschlossenen Periode ist etwas, das jetzt korrigiert werden muss, während ein Hinweis bei einem Forecast zeigt, wo im Plan noch Annahmen stecken – nicht, wo die Bücher falsch sind.

Die angewandte Toleranz orientiert sich zudem an der tatsächlichen Darstellung der Aufstellung – an der Berichtseinheit, nicht an einem festen Betrag –, sodass eine auf Tausend oder Millionen gerundete Bilanz nicht allein wegen der Rundung einen falschen Fehlschlag auslöst. Schlägt tatsächlich etwas fehl, wird die gemeldete Differenz exakt angegeben, nicht als vages „ungefähr passt schon”. Und weil die Prüfung deterministisch ist, liefert derselbe Modellzustand jedes Mal dasselbe Ergebnis – man kann diesen Gesundheitscheck also über den gesamten Abschlusszyklus hinweg wiederholt durchführen, ohne dass das Ergebnis zwischen den Läufen abweicht.

Nach dem eigenen Kalender laufen lassen, nicht nach dem des Prüfers

Der Prüfungsdruck verteilt sich nicht gleichmäßig übers Jahr – er konzentriert sich rund um die Einreichungsfrist und um jede Änderung des Prüfungsstatus, etwa das Überschreiten einer Schwelle für die Befreiung kleiner Unternehmen oder den Wechsel des Prüfers. Genau in den Monaten vor dieser Einreichung zahlt sich ein bewusster Gesundheitscheck aus: Fällt eine gebrochene Identität im November auf, ist es eine stille Korrektur; findet ein Prüfer sie im März, wird daraus eine Anfrage, die zu mehreren weiteren führt – der Art, wie sie unter Anfragen aus der Prüfungs-Fieldwork beschrieben sind. Den Verifier als feste Pre-Audit-Gewohnheit laufen zu lassen – statt sich nur darauf zu verlassen, dass er einen Fehler beim Export abfängt – ist das, was einen Controller bereits wissend in die Fieldwork gehen lässt, welche Zahlen standhalten, noch bevor irgendjemand danach fragt.

Für wen das gemacht ist

Das ist für Controller, die einen sauberen Durchlauf über die Zahlen wollen, bevor ein Prüfer danach fragt, für CFOs, die einen neuen externen Prüfer an Bord holen und noch nicht wissen, wie tief dieser graben wird, und für alle, die schon einmal gesehen haben, wie ein Workbook nur deshalb „aufging”, weil eine Differenz in eine Ausgleichsposition gebucht und nie wieder geprüft wurde. Die Mechanik hinter der Prüfung selbst finden Sie unter So funktioniert Verifizierung; den Rest davon, wie ein belastbarer Abschluss vor, während und nach der Fieldwork aussieht, finden Sie im Finanzteam-Anwendungsfälle-Hub.