DOA Agent
The delegation exists. It is a document. Whether it operated on a given invoice is a separate question, usually answered months later by someone testing a sample.
Nothing is approved by someone who isn't allowed to approve it.The delegation of authority is applied at entry rather than audited afterwards, against limits and tolerances you define, with every override logged against a named user.
What it checks
On every invoice, not a sample.
- Approver against the limit for that value, that category, that entity
- Splitting — two entries just under a limit that together cross it
- Maker and checker are actually different people
- Overrides recorded against a named user with a reason
What it reads, what it writes
Reads
The delegation matrix and your defined limits · Invoice value, category and entity · The approval chain as it happened
Writes
A block where the approval exceeds authority · The rule that was applied · An override log entry where someone went past it deliberately
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 a category is ambiguous and two limits could apply, the lower is enforced and the case is named. It is the reversible direction — an unnecessary approval costs a day, an unauthorised one costs the control.
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→