Period Agent
Most cut-off errors are not deliberate. They are an invoice for March processed in April, booked on the day it was keyed.
Nothing is posted into a closed period.The period is checked at the moment of posting, and cut-off is applied by the date of the event rather than the date someone got to the paperwork.
What it checks
On every invoice, not a sample.
- The period is open for this entry type and entity
- The event date, not the entry date, decides the period
- Accruals raised for what belongs in the period but has not arrived
- Prior-period items routed as adjustments rather than posted quietly
What it reads, what it writes
Reads
Period status per entity · Event dates on the transaction · Accrual policy
Writes
The entry in the correct period · An accrual where the document has not arrived · A routed adjustment where the period is closed
Where it sits in the team
Agents do not work alone. Each one hands its result to the next, so a finding raised here shows up as context downstream rather than being re-derived.
Hands to it
It triggers
When it isn't sure
Where the event date is genuinely unclear — a service spanning a period end — the entry is split or flagged rather than assigned to whichever period is convenient.
Any check that runs on every transaction will meet cases it cannot settle. What makes a control trustworthy is not that it never hesitates — it is that hesitation produces a named question for a person, rather than a silent pass or a silent block.
See what this one finds in your last 90 days.
One export. No connector. We come back within a working day.
$Check your savings→