„Posting Date is not within your range" - was das bedeutet (und wie man es sauber löst)
Ein typischer Moment im Tagesgeschäft:
User will „nur schnell eine Rechnung buchen" - und Business Central sagt:
Posting Date is not within your range.
Der User ist frustriert.
Der Support wird angerufen.
Und die Frage ist: „Was soll das heißen? Gestern ging es noch!"
Und das Spannende ist:
Der Fehler ist kein Bug - er ist ein Schutzmechanismus.
In diesem Artikel schauen wir uns an, was dieser Fehler wirklich bedeutet, wo man den Datumsbereich einstellt und warum man ihn nicht einfach „abschalten" sollte.
1) Was bedeutet der Fehler eigentlich?
Der Fehler sagt dir:
Das Datum, mit dem du buchen willst, liegt außerhalb des erlaubten Zeitraums.
Business Central prüft beim Buchen zwei Dinge:
- Ist das Buchungsdatum (Posting Date) grundsätzlich erlaubt?
- Darf der aktuelle Benutzer in diesem Zeitraum buchen?
Das ist kein „allgemeines Buchungsverbot" - sondern eine benutzer- und zeitraumabhängige Regel.
Und genau das führt in der Praxis zu Verwirrung.
2) Die 2 häufigsten Ursachen (90% der Fälle)
Es gibt zwei zentrale Stellen, an denen der erlaubte Buchungszeitraum definiert wird.
Ursache A: User Setup - Allow Posting From / To
Das ist die benutzerspezifische Einstellung.
Du findest sie unter:
User Setup → Zeile für den User → Felder:
- Allow Posting From
- Allow Posting To
Klassiker:
Das To-Date ist auf Monatsende gesetzt (z. B. 31.01.2026).
Am 1. Februar will der User buchen - und plötzlich geht es nicht mehr.
Typischer Projektmoment:
„Aber gestern ging es noch!"
Ja - weil „Allow Posting To" oft auf Monatsende gesetzt war, und jetzt ist ein neuer Monat.
Wichtig:
Wenn im User Setup nichts eingetragen ist, greift der globale Zeitraum aus dem General Ledger Setup.
Ursache B: General Ledger Setup - Allow Posting From / To
Das ist der globale Zeitraum.
Du findest ihn unter:
General Ledger Setup → Felder:
- Allow Posting From
- Allow Posting To
Verhalten:
Wenn im User Setup kein Datumsbereich definiert ist, gilt dieser Zeitraum für alle User.
Wenn im User Setup ein Datumsbereich definiert ist, wird zusätzlich geprüft, ob er innerhalb des globalen Zeitraums liegt (je nach BC-Version und Setup-Interpretation).
Best Practice:
Der globale Zeitraum sollte die „Außengrenzen" definieren - und spezifische User können innerhalb dieses Zeitraums feiner eingeschränkt werden.
3) Warum das in Projekten ständig passiert
Dieser Fehler ist einer der häufigsten in Business-Central-Projekten.
Typische Gründe:
Monatsabschluss
Am Monatsende wird das To-Date gesetzt, um weitere Buchungen zu verhindern.
Am Monatsersten wird vergessen, es wieder zu öffnen.
Ergebnis: Niemand kann buchen.
Jahresabschluss
Noch kritischer - oft wird der Zeitraum komplett geschlossen.
Und dann versucht jemand, eine Stornobuchung zu machen - scheitert.
Migration / Cutover
Bei Go-Live wird oft ein „harter Cut" gemacht:
- Alt-System bis 31.12.2025
- BC ab 01.01.2026
Und dann versucht jemand, rückwirkend zu buchen - funktioniert nicht.
Key User bucht rückwirkend
Ein User hat temporär erweiterte Rechte bekommen (z. B. für Korrekturbuchungen).
Danach wird vergessen, den Zeitraum wieder einzuschränken.
Job Queue User mit falschem Setup
Automatische Prozesse (z. B. nächtliche Buchungen) haben oft einen eigenen User.
Dieser User hat keine gültige Posting Range - und scheitert.
Das ist besonders tückisch, weil:
- manuell funktioniert es
- nachts scheitert es
Mehr dazu gleich.
4) Die fiesen Sonderfälle (die man erst nach 3 Stunden merkt)
Jetzt wird es richtig praxisnah.
Das sind die Dinge, die einen in Projekten in den Wahnsinn treiben.
a) Posting Date vs. Document Date
Viele User ändern das Document Date - und wundern sich, dass der Fehler trotzdem kommt.
Der Unterschied:
- Document Date = Belegdatum (informativ, z. B. auf Rechnung)
- Posting Date = buchungsrelevant, entscheidet über Periode
Business Central prüft immer das Posting Date - nicht das Document Date.
Wenn du also das falsche Feld änderst, ändert sich nichts.
b) Journal Lines: Default Posting Date
In Journals (z. B. General Journal, Item Journal) wird oft automatisch ein Datum vorgeschlagen:
- Work Date
- Today
- oder das letzte verwendete Datum
Wenn das Work Date falsch eingestellt ist (z. B. noch auf dem alten Jahr), bucht man versehentlich ins falsche Datum.
Typisches Szenario:
User kommt aus dem Urlaub, öffnet BC, Work Date steht noch auf 23.12.2025 - und er bucht versehentlich ins alte Jahr.
c) Hintergrundprozesse (Job Queue)
Das ist besonders wichtig - und passt perfekt zum Thema GuiAllowed:
Problem:
- Job Queue bucht ebenfalls
- hat oft einen eigenen Service User oder Job Queue User
- dieser User hat oft keine gültige Posting Range
Ergebnis:
- Manuell funktioniert es (weil dein User-Zeitraum stimmt)
- Nachts scheitert es (weil der Job Queue User keine Rechte hat)
Das ist einer der heimtückischsten Fehler überhaupt - weil er:
- nicht im Test auftritt
- erst in Produktion sichtbar wird
- und dann mitten in der Nacht
Typischer Support-Call um 8:00 Uhr morgens:
„Die Buchungen sind nicht durchgelaufen!"
Und der Grund: Der Job Queue User hatte keine valide Posting Range.
d) Company-spezifische Settings
Wenn du mehrere Mandanten hast:
User Setup kann pro Company unterschiedlich sein.
Das bedeutet:
- In Company A darfst du buchen
- In Company B nicht
e) Accounting Periods / VAT Periods
In manchen Setups gibt es zusätzlich:
- Accounting Periods (können geschlossen werden)
- VAT Periods (Umsatzsteuerperioden)
Wenn eine Accounting Period geschlossen ist, kann auch der beste Posting Range nichts daran ändern.
5) Warum man den Fehler nicht einfach „abschalten" sollte
Jetzt kommt der entscheidende Punkt.
Viele Projekte haben die Versuchung:
„Lass uns einfach den Posting Range auf 01.01.1900 bis 31.12.2099 setzen - dann haben wir Ruhe."
Das ist eine schlechte Idee.
Hier ist warum:
Posting Range ist eine der wichtigsten internen BC-Kontrollen
Dieser Mechanismus schützt vor:
- Buchungen in geschlossene Perioden
- versehentlichen Rückdatierungen
- Manipulationen (bewusst oder unbewusst)
- Chaos im Monatsabschluss
Wenn du den Posting Range komplett öffnest, verlierst du:
- Periodenabgrenzung
- Nachvollziehbarkeit
- interne Kontrolle (IKS / SOX-relevant in vielen Firmen)
- Sauberkeit in Abschlüssen
Was passiert, wenn der Range offen ist
Szenarien aus echten Projekten:
- User bucht versehentlich ins Vorjahr
- Jahresabschluss ist offiziell fertig - aber jemand bucht noch was nach
- Prüfer / Wirtschaftsprüfer stellt fest: Zahlen haben sich geändert
- Excel-Export aus Dezember passt nicht mehr zu aktuellen Daten
Das sind genau die Situationen, die in Projekten eskalieren.
Business Central ist ein Buchhaltungssystem - keine Notiz-App
BC ist designed für:
- Ordnung
- Nachvollziehbarkeit
- Compliance
Posting Range ist ein zentraler Teil davon.
Wenn du das „abschaltest", arbeitest du gegen das System.
6) Best Practices (kurz & pragmatisch)
Hier ein paar bewährte Ansätze aus echten Business-Central-Projekten.
✅ Empfehlung 1: Posting Range bewusst steuern
Definiere einen klaren Prozess:
- Am Monatsende: To-Date auf Monatsende setzen (z. B. 31.01.2026)
- Nach Freigabe durch Buchhaltung: wieder öffnen (z. B. auf 28.02.2026)
- Bei Sonderbuchungen: temporär für einzelne User öffnen
Das bedeutet:
- Buchhaltung hat Kontrolle
- Prozess ist sauber
- Fehler werden vermieden
✅ Empfehlung 2: Extra Integration User
Wenn du Integrationen hast (Job Queue, Power Automate, API), erstelle:
- eigenen User für Integration
- klarer Posting Range (z. B. immer aktuelles Jahr)
- feste Permission Sets
Dann ist klar:
- Wer bucht was
- Welche Zeiträume sind erlaubt
- Troubleshooting ist einfacher
✅ Empfehlung 3: Work Date bewusst nutzen
Das Work Date ist ein unterschätztes Werkzeug:
- Setzt das Standard-Posting-Date in vielen Pages
- Kann bewusst gesteuert werden
- Aber: auch eine Fehlerquelle
Best Practice:
User schulen, Work Date zu prüfen - gerade nach Monats-/Jahreswechsel.
✅ Empfehlung 4: Getrennte Zeiträume für Key User
Manche User brauchen mehr Flexibilität (z. B. Controller, Buchhaltungsleitung).
Gib diesen Usern:
- erweiterten Posting Range (z. B. 3 Monate zurück)
- aber: dokumentiere das
✅ Empfehlung 5: Monitoring für geschlossene Perioden
Checke regelmäßig:
- Wer hat welchen Posting Range?
- Gibt es User mit „ewig offenen" Zeiträumen?
- Sind Job Queue User korrekt konfiguriert?
Das kannst du z. B. mit:
- Power BI Report
- oder einfach regelmäßiger manueller Prüfung
7) Troubleshooting Checkliste (SEO Gold)
Wenn der Fehler auftritt, geh diese Schritte durch:
| Schritt | Was prüfen? |
|---|---|
| ✅ Welches Datum wird verwendet? | Posting Date (nicht Document Date!) |
| ✅ User Setup prüfen | Allow Posting From / To für diesen User gesetzt? |
| ✅ General Ledger Setup prüfen | Globaler Zeitraum stimmt? |
| ✅ Ist es ein Job Queue User? | Hat der Service User einen validen Posting Range? |
| ✅ Work Date prüfen | Steht das Work Date auf dem richtigen Datum? |
| ✅ Mandant korrekt? | User Setup kann pro Company unterschiedlich sein |
| ✅ Accounting Period geschlossen? | Periode selbst gesperrt? |
| ✅ VAT Period geschlossen? | Umsatzsteuerperiode zu? |
Diese Checkliste löst etwa 95% aller Posting-Date-Fehler in Projekten.
Fazit
Business Central blockiert Buchungen außerhalb des Datumsbereichs nicht, um nervig zu sein - sondern um Abschlüsse stabil zu halten.
Wenn der Fehler auftaucht, ist das fast immer ein Hinweis auf:
- fehlende Abschlussprozesse
- unklare Zuständigkeiten
- oder vergessene User-Konfigurationen
Die Lösung ist nicht, den Posting Range komplett zu öffnen - sondern ihn bewusst zu steuern.
Dann wird aus einem „nervigen Fehler" ein wertvolles Kontrollinstrument.
Wenn Posting-Date-Fehler in Projekten regelmäßig eskalieren, liegt es fast nie an Business Central - sondern an fehlenden Prozessen rund um Monatsabschluss und Berechtigungskonzept.