Ayion Meru Assure
Evidence pack
Finance operations
Period: September 2026
- Coverage
- 94%
- Controls
- 7
- Exceptions
- 3, all closed
Chain verified
4a17…c9e2 · verifiable without Ayion
Finance operations
Invoices chased, vendors paid, and every step evidenced.
Meru Run works the queue: overdue invoices investigated, follow-ups written, vendor changes and journals prepared. Meru Assure holds the limits: thresholds, segregation of duties, and approvals bound to the amount and the record.
Illustration · the daily workspace, Finance operations
Needs attention
3-
Vendor master change on Acme Supplies
Held -
Refund above limit: order 88213
Held -
Reconciliation mismatch: journal JE-1042
Blocked
Active work
2-
Chasing 14 overdue invoices
-
Preparing month-end accruals
Pending decisions
2-
Pay INV-20418
Your approval -
Write off INV-19980
Your approval
Completed
4-
Paid INV-20402
Reconciled -
Paid INV-20399
Reconciled -
Vendor bank change verified
Reconciled -
Posted JE-1039
Reconciled
The work Run takes on
Four jobs, done the way a good analyst would do them.
Each one is bounded: a purpose, the systems it may read, the actions it may take, and a definition of done that a person agreed to first.
-
Investigate an overdue invoice
Pull the invoice, the purchase order, the receipt and the payment run, work out where it stopped, and put the answer in one place instead of in six tabs.
-
Write the follow-up
Draft the chase to the vendor or the internal owner with the evidence attached, and send it only where the approval rules allow sending.
-
Prepare a vendor-master change
Assemble the requested change, the supporting document and the segregation-of-duties check. Bank details are the fraudster’s favourite field, so the change is prepared and never self-approved.
-
Prepare the journal
Draft the entry, attach the support, and hand it to the approver named in the control. Posting happens after approval, not before it.
The controls Assure applies
Business rules, not model settings.
Each control is evaluated before the action runs, whichever agent proposed it, and the decision goes into the record either way.
Controls are set per action and per pack, and they apply to an agent you bought as much as to one of ours.
| Control | What it holds | Example |
|---|---|---|
| Threshold | An amount above which a person decides | Payments above USD 10,000 go to the controller |
| Segregation of duties | The agent that changes a vendor cannot pay it | Vendor-master change and payment run sit in different roles, agents included |
| Journal approval | Entries are prepared, never posted unreviewed | Any entry above the materiality line goes to the financial controller |
| Credit limit | A ceiling on what may be granted without review | Credit notes above the limit are held rather than issued |
| Reversibility gate | Irreversible actions need an explicit authorisation | A payment cannot be recalled, so it is authorised, never inferred |
| Kill switch | One control stops the pack mid-run | Turned off at close, or when the mismatch rate crosses a line |
The evidence pack
The audit asks. The period answers.
One export for the period: the control matrix, the sample of approvals, the reconciliation result, the exceptions and how they closed, and a completeness statement that says what could not be observed.
It reads without Ayion, because a record that needs the vendor to interpret it is not evidence.
How Assure works Illustration · sample evidence pack, September 2026
Control matrix
Page 4 of 18| Control | In scope | Breaches | Sampled | Result |
|---|---|---|---|---|
| Payment threshold | 1,284 | 0 | 40 of 212 | Pass |
| Vendor bank change | 18 | 0 | 18 of 18 | Pass |
| Segregation of duties | 1,284 | 2 | 40 of 212 | Exceptions closed |
| Journal approval | 96 | 1 | 24 of 96 | Exception closed |
| Duplicate payment | 1,284 | 0 | All | Pass |
Period completeness. 94% of consequential actions in the period were observed through the MCP proxy and NetSuite change feeds. The remaining 6% ran through a support channel with no change feed, and are declared as a gap rather than assumed to have succeeded.
The systems it is built for
Where finance work actually lives.
The pack is built for these categories of system. Which connectors are live and which are planned is listed on the packs page, with nothing shown as available before it is.
Packs and integrations-
ERP and accounting
The ledger, the sub-ledgers and the close.
-
Billing and payments
The payment run, the bank file and the card rails.
-
Spend and cards
Requests, approvals and the receipts that go missing.
-
Warehouse and reporting
Where the numbers end up when somebody asks a question.
Measured, not promised
Four numbers, reported the same way every time.
Every pack reports the same set, and a pilot reports them whether or not they flatter us.
A pack that cannot report these is not finished, whatever it can demonstrate.
| Metric | What it counts |
|---|---|
| Completion rate | Work items an agent finished to the completion criteria, without a person taking over. |
| Human correction rate | Completed work a person then changed, and what they changed. |
| Exception rate | Actions stopped by a control, held for approval, or reconciled to a mismatch. |
| Cost per completed workflow | Model, execution and retry cost for one finished item, retries included. |
See it on your own ledger.
A paid 90-day pilot on your systems, your agents and your work. You keep the evidence pack it produces.