Conditions, not code
Amount thresholds, PO match state, tolerance, vendor history, GL account exclusions, entity, department. Composed by a controller in an afternoon rather than requested from engineering.
AI governance
Level 2 means an agent acts inside policy. That is meaningless unless someone in your finance team can actually author the policy — and can see what it would have done before turning it on. This is that surface.
Post a coded vendor bill automatically when all of these hold:
What it does
Amount thresholds, PO match state, tolerance, vendor history, GL account exclusions, entity, department. Composed by a controller in an afternoon rather than requested from engineering.
Every draft policy runs against your last quarter and reports what it would have auto-posted, what it would have held, and — critically — how many of the auto-posts your team later corrected.
A policy change creates a new version. Every posted transaction records the exact version that permitted it, so a year later you can show what the rule was at the time.
A policy cannot grant more than the agent’s authority level allows. Writing a rule that would auto-release payment is rejected at save, not at run time.
Controllers author policies; administrators grant authority levels. Deliberately different people, because one person doing both is the control failure.
If a policy that was safe starts producing corrections — because your vendor mix changed — it flags rather than continuing quietly.
Asking a controller to write a rule that will automatically post financial transactions is asking them to accept an unbounded risk on the basis of a description. Reasonably, most refuse — and then Level 2 never gets enabled, and the automation you bought sits unused at Level 1 forever.
Running the draft policy against your own last quarter changes that conversation entirely. Instead of "do you think this rule is safe," it becomes "this rule would have auto-posted 412 of your last 1,284 bills, and of those, four were subsequently corrected by your team." That is a decision a controller can actually make.
Simulation reports both how much a policy would automate and how many of those automated postings your team later corrected. The second number is the one to optimise, and it moves in the opposite direction to the first.
A policy with a single condition automates the most and has the worst correction rate. Adding conditions reduces coverage and improves safety. Most customers settle at three or four conditions, which is a judgement about their own risk tolerance rather than something we should be making for them.
Policy authorship sits with the controller. Authority levels — which agent may operate at which level at all — sit with an administrator. Those are deliberately different permissions and, in most of our customers, different people.
The reason is straightforward: if one person could both raise an agent to Level 2 and write the policy defining what Level 2 permits, they would hold an unreviewed ability to automate financial postings. Splitting it means a policy is always constrained by a grant somebody else made.
Some customers go further and require two administrators to approve any authority increase. That is a configuration we support, and for companies with a private-equity sponsor or a lender covenant it is usually worth turning on.
A rule that would permit an agent to release funds, close a period, or post into a closed period is rejected when you try to save it, with the reason shown. The permission model is the outer boundary and policy operates strictly inside it.
Questions
Send a quarter of bills and we will simulate several policy shapes against your own history.