Backdated entries
See which entries were posted well after they were entered, and which of those crossed a month boundary.
Do this as part of your month-end review, or any time you want to know what's been dated into a month after the fact. Find it under Accounting, then Backdated Entries.
Backdating is normal and legitimate — a vendor bill is dated when the vendor dated it, not when it landed on your desk. This screen isn't there to stop it. It's there so it's visible, and so the entries that crossed from one month into another are easy to pick out.
The two dates on every entry
Every entry on your books records two things:
- Posted for — the day you're putting the money on the books. You choose it, and it's the one that decides which month the entry lands in.
- Entered on — the moment it was actually typed in. The system stamps this, and nobody can change it, ever.
That second one is what makes the first one safe to allow. Because there's an unalterable record of when something was really keyed, you can date an entry where it genuinely belongs without that being invisible.
The gap between the two is the lag, and that's what this screen sorts on.
Open Accounting, then Backdated Entries. By default it shows entries posted 7 or more days after they were entered, longest lag first.
Adjust the Lag threshold (days) if you want a wider or narrower net, then click Apply. Set it to 0 to see everything with any lag at all; raise it to catch only the extreme cases.
Look at the amber rows first. A row tinted amber and marked crossed period is one where the month it was entered in and the month it was posted for are different months. Those are the ones worth a second look — a lag inside a single month rarely changes anything you reported.
Click Export CSV if you want to hand the list to your accountant. The file carries more than the screen does — both months as separate columns, whether it crossed a period, the transaction type, the location and the timezone it was judged in.
Reading the table
| Column | What it tells you |
|---|---|
| Posted for | The date the entry is booked on, and the month that puts it in |
| Entered on | When it was actually keyed, and the month that fell in |
| Lag | Days between the two — plus crossed period when the months differ |
| Account | The account code and name it hit |
| Amount | The value of the entry |
| Reference | The document reference, with its description underneath |
What happens behind the scenes
- Nothing. This screen only reads. It doesn't change entries, flag them on anyone else's screen, or stop anything from posting. It's detection, not prevention — closing the period is the prevention half.
- Lag is judged in your shop's timezone, so an entry keyed at 6pm local doesn't show a spurious extra day just because it was already tomorrow in UTC.
- The list is capped at 500 rows. If you hit the cap, the screen says so — raise the threshold to narrow it down rather than assuming that's everything.
Troubleshooting
Two likely reasons. The lag may be under your threshold — try setting Lag threshold (days) to 0 and clicking Apply. Or the entry may be older than the window this screen scans; it looks at recent entries, not your whole history.
It probably isn't. A bill that arrived three weeks late and was dated correctly to when the vendor issued it should show a long lag — that's the screen working. What deserves attention is a long lag that also says crossed period, because that one moved money between two months you may have already reported on.
Not from the screen — there's no month picker on it yet. Sorting is longest-lag-first, and the crossed period marker is usually the faster way to find what you're after. The CSV export includes both months as columns, so filtering there is straightforward.
You don't have accounting access. The screen is limited to owners, managers and accounting, and it redirects without explaining. Ask your owner or manager to adjust your role under Settings, then Users & Permissions.