Warum Ihr Odoo-Umsatz nicht zur GuV passt

Der übliche Weg zu einer Umsatzzahl in Odoo führt über account.move: alle Belege vom Typ Kundenrechnung, Status gebucht, Rechnungsdatum im Zeitraum, amount_untaxed summiert. Das ist naheliegend, in fünf Minuten gebaut — und es lässt systematisch etwas aus.

Der Filter, der die Lücke erzeugt

account.move enthält nicht nur Rechnungen. Das Feld move_type kennt unter anderem out_invoice (Ausgangsrechnung), out_refund (Gutschrift), in_invoice, in_refund — und entry. Ein entry ist eine Buchung ohne Beleg im Sinne einer Rechnung: manuelle Umbuchungen, Bankauszüge, Lohnverrechnung, Abgrenzungen, Eröffnungsbuchungen.

Sobald Sie move_type in ('out_invoice','out_refund') filtern, sind alle entry-Buchungen draußen. Wenn Ihre Buchhaltung Erlöse teilweise direkt bucht — was in kleineren Unternehmen die Regel und nicht die Ausnahme ist — fehlen genau diese Beträge in Ihrer Auswertung. Der Steuerberater sieht sie, weil eine GuV nach Konten fragt und nicht nach Belegarten.

Der zweite Fehler: client-seitig summieren

Der zweithäufigste Grund für eine falsche Umsatzzahl ist banaler. Eine Abfrage holt Rechnungszeilen mit einem Limit — 200, 500, 1000 — und die Anwendung addiert, was zurückkommt. Bei 1200 Rechnungen im Zeitraum ist das Ergebnis still falsch, und zwar immer nach unten. Niemand merkt es, weil keine Fehlermeldung erscheint.

Richtig ist eine serverseitige Aggregation: read_group summiert in der Datenbank über alle Treffer, unabhängig davon, wie viele Zeilen die Oberfläche anzeigt. Faustregel: eine Zahl, die als Fakt dargestellt wird, darf nie aus einer begrenzten Abfrage stammen. Das Limit gehört an die Detailtabelle, nicht an die Summe.

Der dritte Fehler: Fremdwährung

amount_untaxed steht in der Währung des Belegs. Eine Rechnung über 10.000 USD und eine über 10.000 EUR ergeben zusammen 20.000 von irgendwas. Odoo führt für diesen Fall Felder in Unternehmenswährung mit — bei account.move etwa amount_untaxed_signed. Wer international fakturiert und die _signed-Varianten nicht verwendet, produziert eine Zahl ohne Einheit.

Die _signed-Felder lösen nebenbei ein zweites Problem: das Vorzeichen. Eine Gutschrift (out_refund) trägt einen positiven Betrag mit umgekehrter Wirkung. Summiert man Rechnungen und Gutschriften über amount_untaxed, erhöhen Gutschriften den Umsatz. Über amount_untaxed_signed netten sie korrekt gegen.

Was eine belastbare Umsatzzahl braucht

1. Serverseitig aggregieren, nie über abgerufene Zeilen summieren.
2. Unternehmenswährung verwenden (_signed-Felder), sonst ist die Summe einheitenlos.
3. Gutschriften mitnehmen, mit korrektem Vorzeichen — sonst ist Umsatz brutto gegen Reklamationen.
4. Buchungen ohne Rechnung entscheiden: entweder bewusst ausschließen und die Kennzahl „Fakturierter Umsatz“ nennen, oder über account.move.line mitrechnen und „Erlöse“ nennen. Beides ist vertretbar, unbenannt ist es nicht.
5. Journalauswahl offenlegen. Wer nur bestimmte Journale auswertet, muss das an der Zahl sichtbar machen.

Die Journal-Falle

Wenn Sie Umsatz pro Journal aufschlüsseln, holen Sie die Beträge aus account.move.line über debit und credit — nicht aus den Rechnungsbeträgen. Sonst stehen alle Journale, die überwiegend entry-Buchungen enthalten, mit 0 € da, und die Aufschlüsselung suggeriert, dort passiere nichts.

Die eigentliche Lehre

Eine Kennzahl ist erst dann eine Kennzahl, wenn ihre Definition mitgeliefert wird. „Umsatz“ ist keine Definition. „Netto-Erlöse aus gebuchten Ausgangsrechnungen und Gutschriften, Unternehmenswährung, nach Rechnungsdatum, ohne direkt gebuchte Erlöse“ ist eine — und sie erklärt die Abweichung zur GuV, statt sie zu einem Rätsel zu machen.

Eine Zahl, die niemand nachrechnen kann, ist keine Kennzahl, sondern eine Behauptung.

Genau deshalb zeigt Metrilens an jeder Karte, welchem Zeitraum sie folgt, und behandelt Buchungen ohne Rechnung als bewusste Einstellung statt als stille Annahme. Die Zahl darf abweichen — sie darf nur nicht unerklärt abweichen.