Today I ran four agent workflows against my own books. Between them they drafted a batch of invoices and a set of journal entries, formatted them for import, and handed them to me to review before anything posted. I spent my time on the handful of lines that looked wrong — not on retyping the hundreds that were right.
That split is the whole point of this post. Talented accountants and bookkeepers should not be spending their best hours moving data from one screen to another. That work is mundane, redundant, and energy-draining, and it’s the bottleneck that caps how much a small finance or admin team can get through in a week. People are better used as exception handlers: reviewing completed work, catching what doesn’t fit, and knowing when the rule needs to be broken.
Humans are the exception handlers
Every accounting procedure is a set of rules. Most transactions follow them. A few don’t — a customer paid two invoices with one check, a vendor billed the wrong entity, an asset was sold before its last depreciation run. Those few are where judgment lives, and they’re also the ones that get missed when a person is fatigued from keying in the other 95%.
An agent workflow flips the ratio. The agent does the rule-following. You get a finished draft, a short list of things it flagged, and the time to actually think about them. You are not being replaced; you are being promoted from data entry to reviewer.
That only works if two things are true: you can see exactly where every number came from, and you can back out a mistake cleanly. More on both below.
Why I import through SaaSant
I push batches into QuickBooks through SaaSant, and the main reason is unglamorous: it has an Undo. If a batch of 40 invoices goes in and I find a systemic error — wrong class, wrong date, wrong customer mapping — I can reverse the whole import instead of voiding 40 transactions by hand.
That matters more than it sounds. The biggest objection I hear to automating postings is “what if it’s wrong at scale?” An agent can make the same mistake 40 times as easily as once. A reliable undo turns that from a disaster into a five-minute fix, and it’s a big part of why I’m comfortable running batches at all.
It also handles the multi-entity reality most small firms live in. Accountants and bookkeepers rarely work in one company file. You’re closing three, five, or fifteen entities, often with intercompany activity running between them, and your tooling has to know which file each line belongs in.
Flexibility is the superpower
For small teams and fast-moving businesses, flexibility beats polish. Businesses don’t stand still:
- Procedures change — a new approval step, a new cutoff rule.
- Connected data changes shape — a processor renames a column, a bank changes its export format, a date shows up as text.
- A new department or entity spins up and needs its own classes and accounts.
- Management asks for a new view or measure — margin by location, labor as a percent of revenue by crew.
Hardcoded scripts and Excel macros work until they don’t. Each of those changes means finding whoever wrote the logic, if they still work there, and rewriting it. A skill is different: it’s written instructions plus a small amount of validation code, and the instructions can be edited by the person who understands the accounting. When the procedure changes, you change a paragraph.
The same holds outside accounting. HR teams move the same kinds of data — new-hire packets into payroll, PTO accruals, benefits enrollment changes, headcount reports by department. Any white-collar process where someone reads one system and types into another is a candidate.
A worked example: one customer, two entities, fifteen assets
Here’s the kind of task where this pays off. You sell 15 pieces of equipment to one customer in a single deal. Nine were owned by Entity A and six by Entity B. Each entity keeps its own depreciation schedule.
To book it correctly, for every asset you need to:
- Find it on the right entity’s depreciation schedule (by asset ID, serial number, or description — and descriptions are never consistent).
- Pull the original cost.
- Pull accumulated depreciation through the disposal date, which may mean adding a partial period the schedule hasn’t run yet.
- Compute net book value and the gain or loss against that asset’s share of the sale price.
- Build the invoice to the customer and the disposal entry that removes the asset from the books.
Per asset, the disposal entry looks like this:
Dr Accounts Receivable (allocated sale price)
Dr Accumulated Depreciation (booked through disposal date)
Cr Fixed Asset – Equipment (original cost)
Cr Gain on Disposal (or Dr Loss, if NBV exceeds price)Now do that 15 times, across two company files. It’s a serious afternoon, and it’s exactly the kind of work where a tired person transposes a number.
An agent handles the search, the lookups, the arithmetic, and the formatting. What it should not decide on its own are the judgment calls — and this deal has at least two:
- How to allocate a lump-sum price. If the customer paid one number for everything, how much belongs to each asset? Relative fair value, relative book value, an appraisal? That choice moves gain between entities.
- Who invoices. Does each entity invoice the customer for its own assets, or does one entity invoice for all of it and settle with the other through intercompany? Either can be right. It depends on the customer, the contract, and your tax picture.
That is the exception-handler role in practice. The skill should stop and ask, or at minimum surface its assumption on the first line of output, so you can overrule it before anything is built on top of it.
What it costs
Writing a skill for a task like this — if your procedures are already documented — takes me somewhere around 10 to 20 minutes. After that it’s reusable by anyone in the organization for as long as the procedure holds, and editable when it doesn’t.
Running it doesn’t need the most expensive model. A capable, cost-effective model — Claude Sonnet, or one of OpenAI’s mini models — handles it well. In my own runs a workflow like this costs on the order of fifty cents in tokens. Your number will vary with file sizes and how many assets are in play, but compare it to an afternoon of staff time and the math isn’t close.
The flywheel: validate a few, then branch
Don’t try to automate the whole close in a month. The approach that has worked for me is a flywheel:
- Start with a solid foundation. One output format, one sign convention, one validator, shared by every workflow.
- Validate a few workflows. Pick two or three recurring, well-understood entries. Run them alongside your manual process until you trust them.
- Branch. Each new workflow is a small branch off the foundation that only describes what’s different — which accounts, which direction, which source file. Everything else is inherited, so it stays consistent.
- Repeat. Every validated branch makes the next one cheaper, because the foundation is already proven.
I wrote up the details of that structure in How I Branch AI Skills for SaaSant Journal Entries.
Source documents and tie-back
Accountants want two things from any number they didn’t type themselves: where did it come from, and does it tie? A workflow that can’t answer both is a black box, and nobody should post from a black box.
So every line the agent produces should carry its receipts:
- Source reference — the file name and row (or page) each amount came from. For the asset sale: which schedule, which asset ID, which row.
- Tie-back totals — batch totals that reconcile to something outside the batch. Total cost removed should equal the sum of those assets on the schedules. Total invoiced should equal the contract price.
- Deterministic checks — a script, not the model, confirms debits equal credits and totals tie. A validation result the model wrote about itself is a claim, not a check.
- A flag list — anything that didn’t match cleanly (an asset not found, a description that matched two rows, a schedule that hasn’t run through the disposal date) goes to the top of the output for a human.
This is what makes review fast. Instead of re-deriving every number, you spot-check the references, confirm the tie-outs, and spend your attention on the flags. The foundation I’ve been building puts these pieces in the shared layer so every new workflow gets them for free.
I’ll be honest about the limits, too: a balanced entry can still be the wrong entry. Structural and arithmetic checks catch slips and format drift; they don’t catch a wrong account or a wrong allocation. That’s why the human stays in the loop — not to retype the work, but to judge it.
Where to start
Pick the recurring task your team dreads most — the one that’s all copying and no thinking. Write down the procedure the way you’d explain it to a new hire. That document is most of a skill already.
If you’re an accountant, bookkeeper, or HR lead trying this on your own processes, I’d like to hear which workflow you started with and where it broke. Those stories are more useful than any demo.