Finance close · Accruals
Multi-workflowBank financeClose the month-end accruals gap between accounts payable and the general ledger
Accruals live in the gap between what was received and what was invoiced. Here is a setup where three workflows build the accrual list, a controller approves it, and next month’s true-up runs on its own.
Valnora & Elric team13 min read
- Team
- Financial control and accounts payable
- Manual steps today
- 5
- Build steps
- 10
- Review points
- 5
The problem
Accruals are the part of the close that lives between two systems. Accounts payable knows what has been ordered and invoiced. The general ledger knows what has been booked. The gap between them, services received but not yet billed and invoices that arrive after cut-off, is filled each month by a spreadsheet and a lot of email.
In a bank finance function the gap is wide. Technology contracts, professional services, card scheme fees and facilities costs all arrive on different billing cycles, and each budget holder has to confirm what was actually delivered. The work is repetitive, deadline-bound and easy to get slightly wrong: a duplicate here, a missed reversal there. Each error is small, but they show up as true-up variances the following month and as sampling questions at the year-end audit.
For example, a team preparing 1,200 accrual lines a month at nine minutes a line spends about 180 hours on preparation alone, before review. Control over financial reporting rules, such as the internal control reporting that listed US companies file under the Sarbanes-Oxley Act, also expect that each of those lines can be supported and traced.
How financial control and accounts payable works today
Today, done by hand · Financial control and accounts payable
- 01On day one of the close, AP exports open purchase orders, goods receipts and unposted invoices into a spreadsheet.
- 02Financial control emails budget holders asking what they received but were not billed for, then chases the replies.
- 03An accountant calculates each accrual line by hand and types a short rationale next to it.
- 04The controller reviews the spreadsheet, asks questions by email and signs off a journal batch.
- 05Next month someone reverses the batch and tries to match invoices that arrived against what was accrued.
Where it breaks
- An invoice posted in the same month as its accrual double-counts the cost, and nobody notices until the true-up.
- Replies from budget holders arrive after the cut-off, so material services go unaccrued.
- Support for each line sits in emails and personal folders, so audit sampling turns into a search exercise.
- Reversals are tracked in a separate sheet, and unmatched accruals linger for months.
What the change could be worth
A bank finance team preparing about 1,200 accrual lines across its entities each month.
| Assumption | Value |
|---|---|
| Accrual lines prepared per month | 1,200 lines / month |
| Minutes per line today | 9 min |
| Minutes per line reviewing a proposed line | 3 min |
| Working days to accrual sign-off today | 6 days |
| Working days to sign-off with proposed lines | 3 days |
| Loaded cost of a finance hour | 70 USD |
| Share of lines with support attached today | 55% |
| Share of lines with support attached after | 95% |
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
These figures are an illustrative scenario computed from the assumptions shown, not a customer result. In it, reviewing a proposed line takes three minutes instead of nine, which frees 120 hours a month, about $100k of finance time a year, and brings sign-off forward by three working days.
The outcome you want
A close where the accrual list builds itself from source data, every line carries its calculation and support, possible duplicates are caught before posting, a named controller signs off each batch, and last month’s accruals are matched and trued up without a separate spreadsheet.
Acceptance criteria
- Every proposed accrual line shows its source purchase order, receipt and calculation.
- Possible duplicates are flagged before the controller sees the batch, not after posting.
- The controller approves, adjusts or rejects each batch on one review page, and the decision is stored.
- Prior-month accruals are matched to invoices and the true-up variance is reported by the third working day.
- Exceptions, unreviewed value and variance are visible on one dashboard with last month for comparison.
- Nothing is posted to the general ledger without a named approver.
The solution end to end
The setup uses three workflows that hand work to each other through two tables, with rules, metrics and monitors on top, a dashboard for the close, and one Relay for the chasing.
Data sources and tables. A source pull workflow runs on a Schedule block every morning of the close window. It reads open purchase orders, goods receipts and unposted invoices with an Oracle NetSuite or Snowflake block, or an API block for your ERP, and upserts one row per PO line into an Accrual candidates table in Tables. A second table, the Accrual register, holds what was approved, by whom, and what happened to it next month.
Proposal workflow. For each new row, a Function block calculates the proposed accrual as received minus invoiced, and an Agent block writes a one-line rationale from the PO description and receipt date. The model explains; it never sets the amount.
Rules. Three Rules of type Flag mark possible duplicates, lines with no receipt evidence and lines above materiality. The flags feed both the review page and the monitors.
Controller review. A Human block pauses the run and shows the batch total, the flagged lines first and each rationale. The review link goes to the close channel through a Slack or Microsoft Teams block. The controller fills in the Resume Form with a decision of Approve, Adjust or Reject and a comment. A Condition block then routes approved lines into the Accrual register with the approver’s name.
Reversal and true-up workflow. On day two of the next month, a third workflow queries last period’s register, matches posted invoices by PO number, records the reversal and the true-up variance, and posts unmatched lines to the close channel.
Metrics and monitors. Metrics define accrued value, unreviewed value and the true-up variance rate once, so every panel reads them the same way. Two Monitors watch them: a Critical rule match when any line is a possible duplicate, and a Warning when unreviewed value rises above your limit.
Dashboard. The close dashboard shows those metrics with comparison to the previous period, a waterfall from the GL balance to proposed, approved and reversed amounts, and a table of flagged lines that drills to the source rows.
The Relay. A custom Relay called Close coordinator starts when the unreviewed value monitor alerts. It queries the candidates table, finds lines still waiting on budget-holder confirmation, and drafts a short email to each owner. It runs at the Assist autonomy level with recipients limited to your own domain, so every email waits for Approve & send. It reads tables but cannot write them.
Chat. For ad hoc questions, such as which accruals above $50k still lack a receipt, Chat can query the tables directly.
From purchase order to approved accrual and true-up
Data · ERP and AP sources
- 01Daily scheduleRuns at 06:00 in the close window.
- 02ERP and warehouseOracle NetSuite, Snowflake or API blocks pull POs, receipts and unposted invoices.
- 03Accrual candidatesOne row per open PO line, upserted by PO number.
Workflow · Accrual proposal
- 04CalculateFunction block: received minus invoiced, never below zero.
- 05Screening rulesFlags possible duplicates, missing receipts and material lines.
- 06Draft rationaleAgent block writes one line per accrual from the PO and receipt.
- 07Controller reviewHuman block pauses the run; the Resume Form records the decision.
- 08Accrual registerApproved lines with approver and period.
Workflow · Reversal and true-up
- 09Monthly scheduleRuns on day two of the next month.
- 10Match invoicesMatches posted invoices to last month’s accruals by PO number.
- 11Close channel postSlack block lists unmatched lines and the variance.
Dashboard · Close control
- 12Accruals dashboardAccrued value, exceptions and true-up variance vs previous period.
- 13Duplicate monitorCritical when any line is flagged as a possible duplicate.
- 14Unreviewed valueWarning when unreviewed accruals rise above your limit.
Relay · Close coordinator
- 15Starts on alertBegins when the unreviewed value monitor fires.
- 16Drafts chasersDrafts emails to budget holders for lines missing confirmation.
- 17Approve & sendEach email waits for the controller’s approval.
Build it
The steps below assume your ERP or warehouse is already reachable from a workflow block. Build the tables first, then the workflows in order, then the rules, metrics and monitors that read them.
Configure it step by step
- 01
Create the accrual tables
Tables → New table
- Accrual candidates: PO number, Supplier, Cost centre, Received amount (Currency), Invoiced amount (Currency), Proposed accrual (Currency), Unreviewed amount (Currency), Status (Select), Rationale (Text).
- Accrual register: Period, PO number, Approved amount (Currency), Approver (Text), Reversed (Boolean), Matched invoice, True-up variance (Currency).
- Use Import CSV with Mode set to Replace all rows to load one prior close as test data.
- 02
Build the source pull workflow
Workflows → new workflow → Schedule block
- Run frequency: Daily, Time 06:00, Timezone set to your close calendar.
- Add an Oracle NetSuite or Snowflake block, or an API block for your ERP, to pull open POs, receipts and unposted invoices.
- Table block, operation Upsert Row, keyed on PO number, writes to Accrual candidates.
- 03
Calculate and explain each line
Accrual proposal workflow → Function and Agent blocks
- Table block, Query Rows, filters Status = New.
- Function block: proposed accrual = received amount minus invoiced amount, never below zero.
- Agent block drafts a one-line rationale from the PO description and receipt date; a Table block writes it back with Update Row by ID.
- 04
Write the screening rules
Rules → New rule
- Rule type: Flag (true / false). "Possible duplicate": invoiced amount is above zero and Status is Proposed.
- Flag: "No receipt evidence": received amount is empty.
- Flag: "Above materiality": proposed accrual is above your threshold. Save each with Create rule.
- 05
Add the controller review step
Accrual proposal workflow → Human block
- Display Data: batch total, line count, flagged lines and the rationale for each.
- Notification (Send URL): post the review link with a Slack or Microsoft Teams block.
- Resume Form: Decision (Approve / Adjust / Reject), Adjusted amount, Comment.
- After Resume execution, a Condition block routes Approve to a Table block that inserts the batch into Accrual register.
- 06
Build the reversal and true-up workflow
Workflows → new workflow → Schedule block
- Run frequency: Monthly, Day of month 2.
- Query Rows on Accrual register for last period, then match posted invoices by PO number.
- Update Rows by Filter sets Reversed and True-up variance; a Slack block posts unmatched lines to the close channel.
- 07
Define the metrics
Metrics → New metric
- Accrued value: Metric type Aggregate, Sum of Approved amount, Display Currency.
- True-up variance rate: Metric type Ratio, a Sum of True-up variance metric ÷ Accrued value, Display Percent.
- Unreviewed value: Aggregate, Sum of Unreviewed amount, which the workflow clears once a batch is decided.
- 08
Set the monitors
Monitors → New monitor
- Rule match on "Possible duplicate", Severity Critical, Check Hourly.
- Metric threshold on Unreviewed value, Fire when it rises above your limit, Severity Warning, Check Daily.
- Save each with Create monitor.
- 09
Build the close dashboard
Dashboards → New dashboard → Build
- KPI card for Accrued value with Compare with set to Previous period.
- Waterfall chart from GL accrual balance to proposed, approved and reversed amounts.
- Table panel of flagged lines with drill to the source rows.
- Share → Subscribe… to send a Daily PDF to the controller during the close.
- 10
Set up the close coordinator Relay
Relays → New Relay
- Specialization: Custom. Name: Close coordinator. Then Create draft.
- What it can use: add Accrual candidates and Accrual register as Table resources.
- Permissions: Autonomy Assist, Email recipients Only my organization’s domain, Approvers set to the controller.
- New responsibility: Trigger When a monitor alerts, Monitor set to the unreviewed value monitor. Then Publish.
What it produces
Each candidate starts as a raw ERP row, becomes a screened and explained line, and ends as part of a batch the controller signs off.
What the solution produces
Raw candidate from the ERP pull (illustrative)
Record- PO number
- PO-88412
- Supplier
- Data centre services
- Cost centre
- Technology infrastructure
- Received
- $84,200 · September service confirmed 30 Sep
- Invoiced
- $84,200 · invoice posted 29 Sep
Proposed accrual line after screening (illustrative)
Record- Proposed accrual
- $0 · received and invoiced amounts are equal
- Flag
- Possible duplicate: an earlier manual accrual of $84,200 exists for this PO
- Rationale
- September hosting was invoiced before month end; the manual accrual should be released.
- Status
- Proposed · listed first for the controller
Controller review page summary (illustrative)
MemoBatch: September close, entity 01. 1,184 lines, $4.82m proposed.
Flagged: 7 possible duplicates ($312k), 12 without receipt evidence, 9 above materiality.
Decision: Adjust. Release the PO-88412 manual accrual; hold PO-88107 until legal confirms the work.
Comment and approver name stored with the batch in the Accrual register.
Where people stay in charge
Where people stay in charge
- Gate 1The controller approves, adjusts or rejects every batch through the Human block before anything reaches the register.
- Gate 2Lines flagged as possible duplicates are listed first on the review page and cannot be skipped silently.
- Gate 3Every chaser email the Relay drafts to a budget holder waits for Approve & send.
- Gate 4The GL team posts the approved batch; the workflow never posts journals without an approved register row.
- Gate 5True-up variances above materiality go back to the controller for commentary before the period is locked.
The dashboard
Month-end accruals · close day 2
Flagged lines
| PO | Supplier | Amount | Flag |
|---|---|---|---|
| PO-88412 | Data centre services | $84,200 | Possible duplicate |
| PO-88107 | Legal advisory | $61,500 | No receipt evidence |
| PO-87990 | Card scheme fees | $212,000 | Above materiality |
The tiles answer the controller’s first questions on each close day: how much is proposed, how much is still unreviewed, how many duplicates are open, and whether last month’s true-up was within tolerance. A daily subscription sends the same view as a PDF during the close window.
Controls and audit
Every workflow run records each block’s inputs, outputs and errors in Logs, so an auditor sampling a line can see the ERP data it came from, the calculation and the decision. Workflows run from a deployed version, so a change to the calculation is reviewed before it reaches the next close. The Relay’s proposals, approvals and sent emails are written to the audit log.
Only the controller and named backups can resume the review step. Row security policies limit cost-centre owners to their own lines on tables, dashboards and subscriptions. Sign-in runs through your identity provider with SSO, and people are provisioned with SCIM. If supplier and cost data cannot leave your environment, run Agent Serve self-hosted with your own model keys or self-hosted models. Zero data retention is available with supported model providers. Some provider features keep data on the provider’s side by design, such as Gemini Deep Research, so they are outside zero data retention.
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
More on how Agent Serve handles access, data and audit on the security page.
Roll it out
Start with one legal entity and run the workflows in shadow next to the spreadsheet for a full close. Measure how many proposed lines matched what the team booked and why the rest differed. Put the success measures on the close dashboard from week one: days to sign-off, unreviewed value on each close day, duplicates caught before posting and true-up variance rate.
Pilot, measure, expand
- Weeks 1–2
Shadow one entity
- Run the source pull and proposal workflows for one legal entity alongside the spreadsheet.
- Compare proposed lines with what the team booked by hand.
Done when: Proposed lines match the manual list or the differences are explained.
- Weeks 3–6
Controller review live
- Switch sign-off to the Human block for that entity.
- Turn on the duplicate and unreviewed value monitors.
Done when: One full close signed off through the review page with no spreadsheet.
- Weeks 7–10
True-up and reporting
- Run the reversal and true-up workflow on the first approved period.
- Publish the close dashboard and subscription to financial control.
Done when: True-up variance reported by the third working day.
| Risk | How to handle it |
|---|---|
| ERP extracts change shape and the pull workflow writes incomplete rows. | Get Schema on the target table and a Condition block that stops the run when expected columns are missing; failures show in Logs. |
| Receipts are booked late, so the calculation understates the accrual. | Keep the budget-holder confirmation step through the Relay’s drafted chasers, and flag high-value POs with no receipt. |
| The model writes a plausible but wrong rationale. | The rationale is explanatory only; amounts come from the Function block, and the controller sees the source fields next to it. |
| Approvers rubber-stamp large batches. | Show flagged and material lines first in Display Data and require a comment when the decision is Adjust or Reject. |
| Too many people can see supplier and cost data. | Row security policies limit each cost-centre owner to their own rows on tables and dashboards. |
Timings are an illustrative plan, not a commitment; your pilot sets the pace.
Before you start
What you need
- Read access to purchase orders, goods receipts and AP invoices through an ERP block, warehouse or API
- Your accrual policy: materiality threshold, cut-off rules and which spend categories are in scope
- One prior close exported as CSV to test the calculation against
- A named controller and a backup to approve batches
- A Slack or Microsoft Teams channel for the close
- Agreement on how approved journals reach the ledger: API import or CSV export
- Row security rules for cost-centre owners who will see the dashboard
Questions teams ask
Questions teams ask
Does Agent Serve post journals to our general ledger?
Only if you build it to. Where your ERP accepts journal imports through an API, an API block can post the approved batch after the Human block step. Many teams prefer to export the approved rows from the Accrual register as CSV and post through their usual import, which keeps the ledger change in the ERP’s own controls.
Who calculates the amounts, the model or the workflow?
The workflow. A Function block does the arithmetic from received and invoiced amounts. The Agent block only writes the one-line rationale, and the controller sees the source fields next to it.
Can the Relay update the accrual tables?
No. Relays can query tables but cannot write to them. All writes happen in the workflows through Table blocks, so every change is in the run logs.
How does the controller approve a batch?
The Human block pauses the run and sends a link. The controller opens the paused execution, reviews the batch, fills in the Resume Form with a Decision of Approve, Adjust or Reject and clicks Resume execution.
Can someone ask questions about the close in plain language?
Yes. Chat can query tables, so a controller can ask which accruals above a threshold have no receipt evidence. Chat does not query metrics or dashboards directly; use Explain this chart on a dashboard panel for that.
Related reading: regulatory reporting prep and the weekly credit committee pack. Request access