Agent customization is the process of encoding a company’s own accounting policy into an agent that executes it. It depends on a documented procedure for the account, a review step before anything posts, and maintenance as the business changes.
Every demo ends with the same question, asked in some version of how this would handle the accounts your team actually closes rather than the tidy one on the screen. It is the right question to ask. What appears in a demo is rarely what stretches your month-end, and closing the distance between the two is the whole job of agent customization.
The answer involves less software configuration than most buyers expect. What makes the result fit one company and not another is the accounting itself: how a prepaid gets treated, which threshold sends an accrual to the controller instead of the staff accountant, what counts as an acceptable variance on an intercompany balance. Those choices come from how the team has decided to do the work, far from any product setting.
That decision is usually undocumented. It rests with whoever has closed the same reconciliation for the last four years, gets explained to new hires verbally, and surfaces in a five-tab spreadsheet only one person can follow. Before any of it can execute, somebody has to write it down.
What Agent Customization Means When The Subject Is Accounting
In most software categories, customization describes settings: fields, permissions, approval routes, the shape of a dashboard. Accounting execution works differently, because the thing being specified is judgment rather than layout. The specification is a procedure, expressed in the language a controller already uses.
That changes who does the specifying. Instructions written for a colleague read nothing like a requirements document, and they do not need to. “Tie the subledger balance to the GL, investigate anything over $5,000 or older than sixty days, and route unresolved items to the assistant controller before day four” is complete as written. Translating it into something a system can execute is the vendor’s job, done alongside the team.
Nominal’s position here is deliberate. The customer supplies the procedure and the accounting judgment, and Deployed Finance Engineers encode it. Your accountants never become a software team, and what runs against your ledger is logic built from their own words, which they can still read back.
That division holds through every account brought into production, which is part of why agentic reconciliation behaves differently from a rules engine pointed at the same data.
You might also like: AI Skills for Accountants: What Your Team Should Learn, and What They Should Never Have To
Why The Written Procedure Comes First
The rule is plain: no SOP, no agent. Nothing goes into production until the treatment behind it has been documented and approved by the people responsible for it.
That rule is what makes customization work. An undocumented procedure gives the encoder nothing reliable to build from, gives a second reviewer nothing to check against, and leaves an auditor six months later with nobody to ask except the individual who has been doing it. Writing it down settles all three at once.
The Half That Turns Out to Be Harder
Teams that have never documented how an account gets closed usually discover that the writing, more than the technology, is the substantial part of the project. Two senior accountants describe the same reconciliation differently. A materiality threshold everyone assumed was $10,000 turns out to be $10,000 in some cases and $2,500 in others, depending on a rule nobody ever articulated.
Surfacing those disagreements is useful regardless of what happens next. The exercise often leaves the close cleaner than it was, before any execution begins. The procedure now exists, it has a version, and it has an owner.
How an Accounting Policy Becomes Something That Executes
The sequence is short, and each step has a named owner. Nothing about it resembles a traditional implementation project with a systems integrator and a nine-month timeline.
Describing the Process in Plain Accounting Language
The team explains how the account gets closed today: the reports pulled and their order, the comparisons made, the differences considered acceptable, and what happens when one is not. Recorded conversations, existing checklists and the current spreadsheet all count as source material. The output of this step is a written procedure everyone recognizes as theirs.
Encoding the Policy So It Can Run
A finance engineer converts that document into working logic, including the exception paths. At this stage, each threshold is set as a condition and each comparison as a matching rule, while “check whether the invoice arrived” gets a branch with two different entries behind it.
The builder speeds up the encoding, and the accounting knowledge behind it is what makes it correct. What separates owning a builder from running agents in production is a subject of its own.
Reviewing Before Anything Reaches the Ledger
The accounting team checks the encoded logic against its own procedure and tests it on a closed period. Output gets compared against what would have been produced manually, and discrepancies get resolved at the source rather than waved through. Authorization to run in production comes from the controller, and approval to post continues to come from a person every month after that.
Keeping It Current as the Business Changes
Accounts drift. An acquisition adds two entities, a new revenue stream changes how commissions amortize, a threshold moves after an audit. Maintenance belongs to the finance engineers who did the original encoding, so revisions arrive the way the first version did, through a conversation about the accounting rather than a support ticket about software.
Planning a deployment this year? The AI Implementation Roadmap covers documentation, sequencing, and the expectations for each phase.
Two Accounts That Show What Has to Be Captured
Abstract descriptions of customization tend to undersell how much accounting specificity is involved. Two ordinary examples make the point better.
Fixed Asset Depreciation
A $1,000 computer depreciated over ten months produces a $100 entry each period. That stays simple until an asset is added midway or disposed of early, at which point the schedule, the monthly amount, and the accumulated balance all change together, and the new figure only makes sense read against the one before it. What gets encoded is a relationship that runs across months, since each month starts from what the last one left behind.
Accrued Liabilities
A contractor finishes work in the last week of the month, and no invoice arrives before the books close. Treatment depends on whether the bill is still expected, estimated from the purchase order, or already received and waiting to be entered, since each case is booked differently. The reversal then has to land correctly once the real amount posts. A team that has never written down which case applies when will not agree on the answer, and neither will anything encoded from that disagreement.
Recommended read: Accrual Automation: How Accounting Teams Handle Expenses That Arrive Before the Invoice
What Becomes Possible Once the Procedure Exists
A documented account is a repeatable one. It can be executed, reviewed, handed to someone new, explained to an auditor, and improved deliberately rather than by whoever inherits the file. Agent customization is what turns that document into completed accounting: a tied-out workpaper, a prepared entry, and an evidence record showing the logic applied and the person who approved it.
The documentation phase pays off most when controllers treat it as accounting work rather than an IT prerequisite. They already know their close better than any vendor will. Writing it down lets that knowledge run every month without anyone personally carrying it, which is also the short answer to why you cannot build this yourself with a generic canvas and good intentions.
Start with one account. Pick whichever consumes the most time and has the clearest right answer, write the procedure, and see what the following month looks like once it stops being manual.
Book a demo to walk through how your most time-consuming close task would be documented, encoded, and reviewed.
About the writer
