Umgehbare Fehler werden verschwinden und es werden nur noch blockierende Fehler oder Warnhinweise verwendet. Darüber hinaus werden die Validierungsregeln vollständig überarbeitet, um sie klarer und einfacher zu gestalten.

Die Daten, wie sie in den Mitteilungen an die Schuldner angegeben sind, müssen weiterhin angegeben werden. Für eine schnelle Bearbeitung der Karte und die Zuordnung zur richtigen Akte wird empfohlen, die Karte so vollständig wie möglich einzureichen, einschließlich des Ausfüllens der nicht obligatorischen Felder, wenn möglich.

Karten für das Einkommensjahr 2026 müssen über die neue Anwendung eingereicht werden, während Karten für frühere Einkommensjahre über die alte Anwendung eingereicht werden müssen.

Für die neue Anwendung ist kein JAVA erforderlich.

Es wird kein herunterladbares Validierungsmodul mehr geben. Sie können die Validierungsregeln jedoch überprüfen, indem Sie eine Testdatei in der Anwendung senden, wenn Sie dies wünschen.

Nein, es ist nicht mehr zwingend erforderlich, die Karten fortlaufend zu nummerieren. 

Die Gesamtbroschüre für BOW 2.0 wird, wie jedes Jahr, erst im Dezember veröffentlicht. Der Grund dafür ist, dass wir alle Gesetzesänderungen berücksichtigen müssen, die möglicherweise bis zum Jahresende umgesetzt werden.

Die definitive Demoversion wird spätestens Anfang 2027 veröffentlicht. Bis dahin werden Demoversionen der Anwendung über verschiedene Kanäle bereitgestellt. 

Nein, es werden keine Vollmachten verwendet. Die derzeitige Rollenverwaltung gilt weiterhin.

Ja, es wird weiterhin möglich sein, Änderungen für frühere Einkommensjahre einzureichen. Zu diesem Zweck wird die alte Anwendung beibehalten, sodass für eine begrenzte Anzahl Einkommensjahre noch Änderungen durch das Hochladen von .XML-Dateien oder Berichtigungen über die Bildschirme vorgenommen werden können. Ab Einkommensjahr 2026 muss dies über die neue Anwendung erfolgen.

Für alle Einheiten sind bestimmte Identifikationsangaben verpflichtend:

• Für eine Person ist der Name (ln) verpflichtend.
• Für eine Organisation ist die Bezeichnung auf Deutsch, Französisch oder Niederländisch (n.de oder n.fr oder n.nl) verpflichtend.

Zusätzlich zu diesen Basisangaben werden, abhängig vom Kartentyp und von der Rolle, die die Einheit in der Karte spielt, weitere Informationen verpflichtend. Die wichtigsten Pflichtfelder für die Einheiten entsprechend ihrer Rolle in der Karte sind in der unten stehenden Tabelle zusammengefasst. Sie müssen für jede Rolle (Erklärender, Begünstigter oder Kind) und für jede Art von Einheit (natürliche Person oder Organisation) mindestens einen der beiden Sätze von Mindestdaten angeben: Mindestangaben 1 oder Mindestangaben 2.

Enthält die Spalte ein Kreuzchen (x), bedeutet dies, dass dieser Datensatz nicht für diese Rolle und diese Art von Einheit zulässig ist.

Ist beispielsweise der Begünstigte der Karte eine Person, müssen Sie mindestens Folgendes angeben:

• entweder die nationale Nummer (= Mindestangaben 1)
• oder die Adresse, die Postleitzahl, die Gemeinde und das Land (= Mindestangaben 2).

Sie müssen auch den Namen angeben, der für jede Person verpflichtend ist.

Wichtig - Sonderregeln pro Kartentyp

Für bestimmte Kartentypen gelten zusätzliche Einschränkungen. Einige Beispiele:

• Kartentypen 281.10, 281.20 und 281.60: Ist die nationale Nummer des Begünstigten nicht angegeben, muss neben dem Namen, der Adresse, der Postleitzahl, der Gemeinde und dem Land auch das Geburtsdatum angegeben werden.
• Kartentyp 281.79: Ist die nationale Nummer des Begünstigten nicht angegeben, muss neben dem Namen, der Adresse, der Postleitzahl, der Gemeinde und dem Land auch die Steueridentifikationsnummer angegeben werden.
• Kartentypen 281.80, 281.81 und 281.84: Unabhängig davon, ob die nationale Nummer angegeben wird oder nicht, sind die Adresse, die Postleitzahl, die Gemeinde und das Land für den Begünstigten verpflichtend.

Beziehen Sie sich für diese Sonderfälle auf die Validierungsregeln, die für jeden Kartentyp spezifisch sind.

Erklärende

Begünstigten

Kind (Karte 281.86)

Achtung: Die Angabe der nationalen Nummer von natürlichen Personen wird gemäß dem Gesetz vom 12. Mai 2024 spätestens am 1. Januar 2028 auf allen Steuerkarten verpflichtend.

Um die Einhaltung dieser Verpflichtung zu gewährleisten, bitten wir die betroffenen Unternehmen und Personen, ihre Systeme bereits jetzt anzupassen, damit sie diese Angabe integrieren können, sobald sie verpflichtend wird.

Das Feld 2010 ist eine interne Referenzangabe des Erklärenden, um die Karte in seinem Schriftverkehr mit dem Begünstigten zu identifizieren. Darin können sich bis zu 20 alphanumerische Zeichen befinden. Zum Beispiel: eine durchgehende Nummerierung der Karten für dasselbe Jahr, denselben Typen und denselben Erklärenden (1, 2, 3 usw.).

Ja.

Nein. Auch wenn es sich im Muster einer Karte befindet, bleibt das Feld 2010 fakultativ.

• Laufende Nummer (2010): Sie ist optional, intern für den Erklärenden und kann von Jahr zu Jahr für verschiedene Kartentypen oder Erklärende verwendet werden.
• Referenzangabe der Karte (k): Sie ist Pflicht und einmalig pro Versender. Sie wird vom Versender und der Verwaltung verwendet, um jede Karte zu identifizieren.

Ab dem Einkommensjahr 2026 können Sie dieses Tool nicht mehr verwenden. In der neuen Version (im Jahr 2026 und später gezahlte Kinderbetreuungskosten) wird es möglich sein, eine Excel-Datei (mit einer spezifischen Struktur) direkt in Belcotax-on-Web hochzuladen. Um zu sehen, welche Anpassungen Sie gegebenenfalls an Ihren Tools oder Eingabeverfahren vornehmen müssen, können Sie bereits jetzt diese  Excel-Datei (XLSX, 21.66 KB) und die  entsprechenden Anweisungen (PDF, 265.18 KB) einsehen, indem Sie die Daten zu den im Jahr 2026 gezahlten Kinderbetreuungskosten entsprechend der Struktur dieser Excel-Datei eingeben.

Ab Februar  2027 können Sie diese Datei direkt in die neue Version von Belcotax-on-Web hochladen.

Die Regeln für die Bescheinigung an die Eltern bleiben unverändert.

Die Daten sind, sofern möglich, aufzuteilen. Ist dies nicht möglich, muss die vollständige Adresse in der Eigenschaft „s“ angegeben werden, die der Straße entspricht.

Anstatt mit XML-Tags zu arbeiten, um die verschiedenen Bereiche zu definieren, verwendet das neue System JSON-Eigenschaften, die für die meisten Bereiche aus einem vierstelligen Zahlencode bestehen. Dieser Zahlencode entspricht für die meisten Bereiche dem bereits in den XML-Tags vorhandenen Code. Beispielsweise wird der Bereich 2.060 der Karte 281.10, der durch den XML-Tag „f10_2060_gewonebezoldigingen“ definiert wurde, nun durch die JSON-Eigenschaft „2060“ definiert.

Die Reihenfolge der Tags ist frei wählbar. Sie können zuerst die obligatorischen Zonen und dann die optionalen Zonen angeben, dies ist jedoch nicht zwingend erforderlich.

Jede Karte muss einen eindeutigen Key haben, um doppelte Einreichungen der Karte zu verhindern. Dieser eindeutige Key hat den Vorteil, dass ein Benutzer die richtige Karte bei Bedarf leicht abändern kann. 

Der Absender kann einer Einheit mehrere Referenzangaben zuweisen, sowohl für Schuldner als auch für Begünstigte. Die Einheiten werden pro Absender gespeichert, sodass Karten nicht von einem anderen Absender überschrieben werden können.  

Sie können die Unterscheidung anhand eines anderen Präfixes in der Referenzangabe des Schuldners vornehmen.

.XML-Dateien können noch für eine begrenzte Anzahl von Jahren über die alte Anwendung eingereicht werden, aber nur für das Einkommensjahr 2025 und frühere. Ab dem Einkommensjahr 2026 sind jedoch nur noch JSONL-Dateien zulässig.
 

Negative Beträge sind nicht zulässig. Es ist auch nicht sinnvoll, leere Felder mit „0“ auszufüllen, da „0“ in einigen Feldern eine andere Bedeutung hat und sich daher nicht auf ein „leeres“ Feld bezieht.

Ja, es ist möglich, jedes Jahr alle Einheiten zusammen zu senden. Es ist auch möglich, alles zusammen erneut zu senden, wenn ein Update erforderlich ist. 

Eine JSON-Lines-Datei kann zwei Kategorien von Dokumenten enthalten: 

1. Mittel
   •  I. Einheiten: Personen und Organisationen
   • II. Angaben einer Kontaktperson beim Absender
2. Karten

Jede Karte muss Verweise auf die Kontaktdaten des Absenders (c) sowie auf die verschiedenen Einheiten enthalten, die mit der Karte zusammenhängen (wie der Erklärende [d] und der Empfänger [b] der Karte).

Die Referenzangaben der Karten müssen für einen bestimmten Absender eindeutig sein, unabhängig vom Jahr. 

Wenn Sie für die Einkünfte 2025 im Februar 2026 eine Karte mit der Referenzangabe 1 senden und für die Einkünfte 2026 im Februar 2027 ebenfalls eine Karte mit der Referenzangabe 1 senden, wird die Karte mit der Referenzangabe 1 die bereits bestehende Karte 1 ändern. Es wird eine Karte für die Einkünfte 2026 erstellt, die Karte für die Einkünfte 2025 wird jedoch gelöscht. 

Um dieses Problem zu vermeiden, sollten Sie eher ein Präfix verwenden, das dem Jahr entspricht. Statt die Karte 1 zu senden, können Sie die Karte 2025_1 und im darauffolgenden Jahr die Karte 2026_1 senden. 

Sie können auch Präfixe für den Kartentyp, die ZDU-Nummer des Erklärenden, das Amt, das die Karten sendet, usw. oder ein anderes System verwenden, mit dem die allgemeine Einmaligkeit der Referenzangaben als Absender gewährleistet werden kann. 

Im neuen Datenformat gibt es keinen Unterschied mehr zwischen den belgischen und den ausländischen Postleitzahlen.

Wenn Ihre Sendung Fehler enthält, wird Ihre Sendung abgelehnt. Falls die Sendung abgelehnt wird, müssen Sie sie nach Vornahme der Berichtigungen in ihrer Gesamtheit erneut senden.

Dies kann durch die Verwendung einer anderen Kartenreferenzangabe erfolgen. Wenn für den Schuldner verschiedene Standorte gelten, ist es sinnvoll, für diesen Schuldner pro Standort eine andere Referenzangabe zu erstellen. 

Die Referenzangabe der Karte wird auch in der Feedback-Nachricht angegeben sein.

Es gibt keine Feedback-Zeile bezüglich der Business-Regeln pro gesendete Zeile, sondern ein Fehlerobjekt pro Fehler in der gesendeten Datei, wobei die Anzahl Fehler begrenzt ist. Das Feedback umfasst die Fehler der ersten 100 Zeilen mit Fehlern; eine Zeile kann mehrere Fehler enthalten. Die Fehlermeldungen enthalten ebenfalls einen Verweis auf den einmaligen Schlüssel der Karte, um schnell herausfinden zu können, wo sich die Fehler befinden. Das Feedback wird im JSON-Format erstellt und entspricht den auf dieser Website festgelegten Bestimmungen.

Diese kann täglich gesendet werden. - Wir empfehlen Ihnen, nicht jeden Tag das gesamte Portfolio der Einheiten erneut zu senden, sondern nur die Änderungen.

• Wenn es keine Änderung in der Präambel gibt, ändert sich auch nichts an den eingereichten Daten.
• Wenn es eine Änderung in der Präambel gibt, insbesondere zusätzliche Daten, werden diese zusätzlichen Daten erstellt.
• Wenn ein Datensatz aus der Präambel entfernt wird:
  • z. B. Einheit entfernt => die vorhandenen Karten bleiben erhalten, ebenso wie die mit den Einheiten verknüpften Einheiten
  • Sie können jedoch den Key, der in dieser gelöschten Einheit gelöscht wurde, nicht mehr wiederverwenden, da er deaktiviert wurde.
  • z. B. Adresse löschen => ist eine Änderung, die als Update der Einheit umgesetzt wird, wobei die ursprünglichen Karten mit den entsprechenden Daten der Einheit erhalten bleiben.

Es wird keine automatische E-Mail mehr generiert. Sie können jederzeit Feedback in der Anwendung anfordern, auch Feedback zu den Karten, die zuvor von einem Kollegen eingereicht wurden, vorausgesetzt, Sie haben dieselbe Rolle.

Ja, es wird weiterhin möglich sein, Karten über die Anwendung einzureichen, entweder durch Sendung einer Sammeldatei oder durch Eingabe in den Bildschirmen.

Dies können Sie vermeiden, indem Sie beide in einer Datei zusammenfassen. Wenn Sie sie jedoch getrennt einreichen möchten, empfehlen wir Ihnen, mit der Versendung der Karten zu warten, bis die Präambel angenommen wurde, da sich diese Karten auf die Daten in der Präambel beziehen. 

Die Entwicklungen für die Inbetriebnahme der API sind noch in vollem Gange. Sobald die technischen Entwicklungen validiert wurden, werden wir die erforderlichen Informationen auf unserer Website veröffentlichen.

Das Senden großer Dateien wird weiterhin möglich sein. Diese Sammeldateien müssen in JSON Lines erstellt werden. Sendungen im .XML-Format werden daher ab Einkommensjahr 2026 nicht mehr möglich sein.

Nein, es wird kein Umwandlungsmodul bereitgestellt. Daher ist es am besten, rechtzeitig mit der Bearbeitung der bereitgestellten Dateien zu beginnen. 

Sie müssen zum Durchführen eines Tests keine Änderungen an Ihrer Datei vornehmen, sondern nur die dafür vorgesehene Schaltfläche verwenden. 

Die Mittel gelten für mehrere Jahre. Folglich müssen Sie die Mittel, die nicht geändert werden, nicht erneut senden. 

Wird ein Teil der Mittel geändert, senden Sie lediglich die aktualisierten geänderten Mittel sowie mögliche neue Mittel.

Anmerkung: Sie können auch alle Mittel zu Beginn des Jahres senden, wenn das für Sie einfacher ist.

Es handelt sich um Read-only-Felder. Sie können keine Read-only-Felder in einem Sammelantrag senden, sie werden jedoch automatisch berechnet. Diese Felder erfüllen einen internen Zweck und sind notwendig, um die Aufstellungen 325 zu berechnen, die automatisch von diesen Karten ausgehend erstellt werden.

Sie dürfen Ihre Karten und Mittel in einer Sendung oder in mehreren Sendungen senden, je nachdem, was Ihnen am besten passt.

Sammelanträge müssen im UTF-8 eingegeben werden und alle Zeichen, auch Sonderzeichen, müssen in diesem Format dargestellt werden.

Über die API gesendete Dateien dürfen höchstens 30 MB groß sein.

Die 10 entspricht dem Kartentyp, in diesem Fall 281.10. Die 2024 gibt an, dass es sich um das Schema für die Einkünfte 2024 handelt. Die 137 entspricht der Version des Schemas.

Nein, jedes Jahr wird für die verschiedenen Kartentypen ein neues Schema veröffentlicht.

Neben dem Unterschied im Format sind die Daten im alten System mit dem XML-Format und im neuen System mit JSON Lines anders strukturiert. Es gibt folglich keine 1:1-Übereinstimmung zwischen den XML-Tags und den JSON-Eigenschaften. Eine XML-Karte entspricht mehreren JSON-Zeilen, die nicht unbedingt in derselben Datei gesendet werden. Es wird ein Vergleich zwischen einer XML-Datei ( Karte10Example.xml (ZIP, 1.81 KB)) und der entsprechenden JSON-Lines-Datei ( Karte10Example.jsonl (ZIP, 563 Bytes)) für eine Karte 281.10 angestellt. 

Es lässt sich insbesondere feststellen, dass bestimmte Elemente, die Teil der Karte in der XML-Datei sind, außerhalb der Karte in der JSON-Lines-Datei definiert sind. So sind die Elemente b (Empfänger), c (Kontaktangaben) und d (Schuldner) der Karte 281.10 in der JSON-Lines-Datei in einer spezifischen Zeile definiert und es wird der Schlüssel (k) in der Karte verwendet, um auf diese Elemente zu verweisen. 

Ja, es ist möglich, die gesendeten Einheiten in der Anwendung einzusehen.

Wenn eine Person ihre nationale Nummer ändert, müssen Sie die nationale Nummer der entsprechenden Einheiten ändern.

Wenn eine ändernde Karte eingereicht wird, wird die alte Karte deaktiviert und die neue Karte aktiviert. Es wird jedoch möglich sein, die ursprüngliche Karte einzusehen. 

Nein, Sie müssen nicht mehr auf die ursprüngliche Sendung verweisen, um Änderungen vorzunehmen. Durch den Verweis auf die Karte kann die richtige Karte identifiziert werden, die geändert werden muss.