In den nächsten Jahren wird fast jedes bulgarische Unternehmen dieselbe Prüfung durchlaufen: SAF-T. Die standardisierte Buchhaltungsdatei für die bulgarische Nationale Agentur für Einnahmen (NAP) wird von 2026 bis 2030 in Wellen eingeführt, gemäß § 17 der Übergangs- und Schlussbestimmungen des bulgarischen Staatshaushaltsgesetzes für 2025: zuerst große Unternehmen oberhalb der Schwellenwerte, bis 2030 dann alle übrigen, einschließlich der für die Mehrwertsteuer registrierten Kleinstunternehmen. Der Rhythmus ist monatlich: Die Datei wird bis zum Ende des Monats eingereicht, der auf den Berichtsmonat folgt, und bei einer Ablehnung bleiben nur 7 Tage für die Korrektur. Mit anderen Worten: Fehler sind teuer, und die Zeit zum Reagieren ist knapp.
Vor diesem Hintergrund hat unser Team SAFTCheck gebaut - ein kostenloses Tool zur Prüfung von SAF-T-Dateien mit einer ungewöhnlichen architektonischen Besonderheit: Die Datei verlässt nie den Browser des Nutzers. In diesem Artikel erzählen wir offen (das Projekt ist unser eigenes), welche Entscheidungen wir getroffen haben, warum und was wir unterwegs gelernt haben. Nicht, weil wir uns selbst auf die Schulter klopfen wollen, sondern weil dieselben Prinzipien für jedes Produkt gelten, das mit sensiblen Daten arbeitet.
Wenn Sie ein ähnliches Tool für Ihr Unternehmen planen: Das ist die Fallstudie, die wir gern gelesen hätten, bevor wir angefangen haben.
Die Aufgabe: Vertrauen gewinnen, wenn man nach Buchhaltungsdaten fragt
Eine SAF-T-Datei ist nicht einfach XML. Darin steckt die gesamte Buchhaltung des Unternehmens für den Monat: Kontenumsätze, Salden, Geschäftspartner, Belege. Das sind Daten, die Buchhalter aus Gewohnheit (und zu Recht) wie ihren Augapfel hüten. Das klassische SaaS-Modell - „Laden Sie die Datei bei uns hoch, wir prüfen sie“ - startet bei diesem Publikum mit einem riesigen Minus. Jeder Upload auf einen Server wirft Fragen auf, die man beantworten muss: Wohin gehen die Daten, wer hat Zugriff, wie lange werden sie gespeichert, was passiert bei einem Datenleck?
Die zweite Besonderheit der Aufgabe war der Zeitpunkt. SAF-T kommt in Wellen, und der Markt bildet sich gerade erst: Die erste Welle betrifft große Unternehmen ab 2026, doch die Fragen beginnen viel früher. Wir wollten ein Tool, das schon in dem Moment nützt, in dem ein Buchhalter zum ersten Mal mit der Pflicht konfrontiert wird, und nicht erst, wenn er eine fertige Datei zum Einreichen hat.
Wir haben die Aufgabe so formuliert: alle Hürden zwischen dem Nutzer und der Prüfung beseitigen. Keine Registrierung, keine E-Mail, kein Upload, kein Preis. Jede beseitigte Hürde ist ein Grund weniger, es nicht auszuprobieren.
Die drei Entscheidungen, die das Projekt geprägt haben
Die Prüfung läuft im Browser
Die Validierung läuft lokal über eine nach WebAssembly kompilierte Version von libxml2. Es gibt keinen Server, der Dateien annimmt - also gibt es auch nichts, was nach außen dringen könnte.
Statische Website
Rund 120 KB beim ersten Laden, brotli-Komprimierung, immutable-Caching. Öffnet sich sofort, selbst auf einem Dienstlaptop über ein Firmen-VPN.
Nur Primärquellen
Alles auf der Website stützt sich direkt auf die Dokumente der NAP, nicht auf Nacherzählungen. Wenn ein Thema neu ist, ist Genauigkeit die einzige Währung.
Entscheidung Nr. 1: Die Prüfung läuft komplett im Browser
Die wichtigste Architekturentscheidung fiel gleich zu Beginn: Die Validierung wird lokal im Browser des Nutzers ausgeführt, mit WebAssembly. Wir haben libxml2 - dieselbe Bibliothek, die seit Jahrzehnten in der Branche XML validiert - zu einem WASM-Modul kompiliert, das das offizielle XSD-Schema der NAP (v1.0.2) lädt und die Datei direkt vor Ort prüft.
Doch das Schema ist nur der Anfang. XSD sagt, ob eine Datei strukturell gültig ist, nicht, ob sie buchhalterisch sinnvoll ist. Deshalb haben wir darauf eigene Prüfungen aufgesetzt:
- Saldengleichungen je Konto und Übereinstimmung von TotalDebit/TotalCredit
- Querverweise - jeder Beleg muss auf einen tatsächlich deklarierten Geschäftspartner verweisen
- UTF-8-Kodierung und Dateiname gemäß Anlage 3
- Prüfziffer der EIK (bulgarische Unternehmenskennnummer) - ein kleines Detail, an dem eine sonst perfekte Datei scheitern kann
Die lokale Verarbeitung bringt doppelten Nutzen. Für den Nutzer: Es kann nichts nach außen dringen, weil nichts hochgeladen wird - das Datenschutzversprechen ist kein Absatz in einer Datenschutzerklärung, sondern eine Eigenschaft der Architektur, die jeder im Netzwerk-Tab seines Browsers überprüfen kann. Für uns: Es gibt keinen Server, der fremde Buchhaltungsdaten verarbeitet, und damit auch nicht die ganze betriebliche und rechtliche Last, die damit einhergeht.
Entscheidung Nr. 2: eine statische Website statt einer Plattform
Da die Validierung beim Client läuft, hat der Server nichts zu berechnen. Deshalb ist die gesamte Website statisch: Der erste Ladevorgang umfasst rund 120 KB, alles läuft über brotli-Komprimierung, und die Assets werden als immutable gecacht. In der Praxis öffnet sich das Tool sofort, selbst auf einem Dienstlaptop über ein Firmen-VPN - genau in der Umgebung, in der unser tatsächliches Publikum arbeitet.
Die statische Architektur hat es uns auch erlaubt, konsequent bis zum Ende zu bleiben: Die Website hat keine Cookies und keine externen Tracker, die Statistik ist eigen und anonym. Es wäre absurd gewesen, zu versprechen, dass die Datei den Browser nicht verlässt, und gleichzeitig das Verhalten der Nutzer an drei Werbeplattformen zu schicken.
Entscheidung Nr. 3: Inhalte nur aus Primärquellen
Die dritte Entscheidung ist nicht technisch, sondern redaktionell: Alles auf der Website stützt sich direkt auf die Dokumente der NAP, nicht auf Nacherzählungen. Wenn ein Thema neu ist und für Anspannung sorgt, ist Genauigkeit die einzige Währung.
So ist rund um die eigentliche Prüfung eine ganze Schicht von Hilfswerkzeugen entstanden. Wir haben ein Nachschlagewerk aller 347 Elemente des Schemas mit den offiziellen Beschreibungen der NAP erstellt, dazu die Nomenklaturen und den nationalen Kontenplan. Hinzu kamen ein Rechner „In welcher Welle bin ich?“ für die Fristen 2026-2030, ein Fehlerglossar mit zehn ausführlichen Seiten und ein Paste-Tool „Erklär mir den Fehler“ sowie ein Verzeichnis aller 188 offiziellen Fragen und Antworten aus dem Dokument der NAP (Version 2, 2026).
Das neueste Teil ist ein Konverter in der Beta: Sie geben Summen- und Saldenliste und Journal als CSV ein und erhalten eine monatliche SAF-T-XML-Datei - wieder komplett im Browser und während der Beta kostenlos. Das ist die logische Fortsetzung desselben Prinzips: Wenn die Prüfung lokal laufen kann, warum nicht auch die Erstellung? In Aktion sehen Sie ihn in der Konverter-App.
Was wir gelernt haben
Geschwindigkeit ist Teil des Vertrauens
Wir sind es gewohnt, Geschwindigkeit als SEO-Kennzahl zu sehen. Hier hat sie sich als mehr erwiesen: Ein Tool, das sich sofort öffnet und ohne Registrierung funktioniert, sendet ein Signal der Seriosität. Das Gegenteil gilt ebenso - eine langsame Website mit E-Mail-Formular vor dem Ergebnis sagt: „Erst geben Sie uns etwas, dann wir Ihnen.“
Datenschutz wird bewiesen, nicht behauptet
Der Unterschied zwischen „Wir geben Ihre Daten nicht weiter“ und „Ihre Daten erreichen uns physisch gar nicht“ ist der Unterschied zwischen einem Versprechen und einer Tatsache. Das Zweite ist schwerer zu bauen, aber unvergleichlich leichter zu kommunizieren - es lässt sich in einem Satz erklären und von jedem technisch versierten Nutzer überprüfen.
Primärquellen sind ein Wettbewerbsvorteil
Inhalte direkt aus dem Schema und den offiziellen Antworten der NAP zu gewinnen, ist langsame und langweilige Arbeit. Genau deshalb macht sie fast niemand - und genau deshalb zahlt sie sich aus. Vor einem Fachpublikum gibt es kein stärkeres Argument, als die Primärquelle exakt zu zitieren.
Was das für Sie bedeutet
Wenn Ihr Unternehmen ein Tool plant, das mit sensiblen Daten arbeitet - finanziellen, medizinischen, persönlichen -, lässt sich der Fall SAFTCheck auf drei übertragbare Erkenntnisse herunterbrechen:
- Clientseitige Verarbeitung ist heute eine realistische Option. WebAssembly ermöglicht anspruchsvolle Berechnungen direkt im Browser. Wenn die Daten den Nutzer nicht verlassen sollen, müssen sie das auch nicht mehr.
- Nicht alles braucht eine Plattform. Eine statische Website mit einem cleveren Frontend kann ein vollwertiges Produkt tragen - schneller, günstiger und sicherer als das entsprechende SaaS, wenn die Berechnungen lokal laufen.
- Beseitigen Sie die Hürden vor der ersten Nutzung. Registrierung, Upload und Preis sind drei Türen, durch die der Nutzer gehen muss, bevor er einen Nutzen sieht. Jede verschlossene Tür kostet Sie Nutzer, von denen Sie nie erfahren werden, dass Sie sie verloren haben.
Nicht jedes Produkt kann (oder sollte) komplett im Browser laufen. Aber die Frage „Kann diese Verarbeitung beim Client stattfinden?“ verdient es, am Anfang jedes Projekts mit sensiblen Daten gestellt zu werden. Lautet die Antwort „Ja“, erhalten Sie eine Architektur, in der Vertrauen nicht mit Worten aufgebaut wird - es ist eingebaut. Und wenn Sie einen Partner suchen, der diese Frage gemeinsam mit Ihnen stellt: Sie wissen, wo Sie uns finden.
