Build Once. Run Every Close.
What we built in this week's Lumera Live: a PO accrual workflow connected to NetSuite, with a reusable month-end run path.
PO accruals are exactly the kind of workflow where finance teams need more than a chatbot. The process requires accurate NetSuite data, accounting logic, review controls, journal entry creation, and a record of what happened each period. In this week's Lumera Live, we built that workflow on Lumera.
What I mean by an agentic workflow
When I talk about agentic workflows in finance, I do not mean a chatbot sitting on top of your ERP. I also do not mean a model making every decision from scratch every time a process runs. That may be useful for exploration, but it is not how I think production finance work should operate.
An agentic workflow is software, AI, and human review working together to automate an end-to-end process. Each part has a job. Software is best for the deterministic pieces: pulling data from NetSuite, running a tested query, applying a rule, creating a journal entry draft, saving a run history, and moving data between systems. AI is best where the work requires interpretation, context, or judgment: reading support, comparing an exception to past patterns, explaining why something looks unusual, or helping build and refine the workflow itself. Humans should stay in the loop where the stakes are high, the answer is ambiguous, or judgment needs accountability.
This is especially important in accounting because the output does not live in a vacuum. It becomes a journal entry, a reconciliation, a board report, a customer communication, or an audit workpaper. The workflow needs to know where the data comes from, what logic was applied, what the system produced, who reviewed it, and what eventually got posted or sent downstream.
In the PO accrual example, the deterministic software layer is what pulls the right NetSuite data, stores each accrual run, and generates the same tested workflow each period. The AI layer helps create and refine the app, reason through the workflow design, debug issues, and eventually handle judgment-heavy extensions like reading vendor communication or explaining unusual accruals. The human review layer is what makes the workflow usable in a real close process: the team can inspect the draft journal entry, make edits, approve it, and only then send it downstream.
The workflow
I started with a simple request:
Build an app that uses our NetSuite integration to pull POs that were received but not yet billed, draft a PO accrual journal entry as a reversing entry, and give me a dashboard where I can generate the accrual each month and review it before sending anything to NetSuite.
There was no special prompt, no long spec, and no custom implementation plan. The important part was that the request described the actual finance workflow. The source system was NetSuite. The output was a draft journal entry. The control point was review before posting. The recurring action was generating the accrual every month.
That is usually the level where finance teams should start. Not with “how do I use AI?” or “what is the perfect prompt?” Start with the workflow your team already runs and describe what needs to happen.
The part that matters
The most useful thing about this demo was not simply that an AI agent could generate an app. That part is impressive, but it is not the full point. The more important thing is what happened after the first build. Lumera created the supporting pieces around the workflow. It created a table to track PO accrual runs, so you can see which periods have had accruals generated. It created an automation that runs when someone generates the accrual. It exposed the generated code instead of hiding it. It kept run logs, errors, and history available.
That is the difference between a clever demo and something a finance team can actually work with. For a process like this, you do not want a model inventing a new NetSuite query every time you close the books. You want the agent to help build the system, then you want the recurring process to run in a predictable way.
In this case, once the app is tested, the monthly run path is straightforward: pick the period, run the accrual, review the draft, and decide what should go to NetSuite. That is the “build once, reuse every close” pattern.
Why API first matters
One question that came up during the session was whether this should be done through an API or through MCP. For a chatbot, MCP can be useful. If you want to ask exploratory questions against data, it can make for a good interface. For close workflows, I want something more deterministic.
If the task is “pull POs received but not yet billed,” that is not a moment where I want the system improvising. I want a tested query against the right NetSuite tables. I want to know which field is being used. I want the logic to be stable from one period to the next.
This is one of the reasons I like API-driven workflows for production finance work. The AI can still help build, debug, and improve the app. But the recurring execution can be software, not a fresh reasoning exercise every month.
The second month is the real test
The first month of any automation is only partly about saving time. You are still learning the process. You are validating the data. You are checking edge cases. You are making sure the review surface gives you enough context to trust the output.
The second month is where the payoff becomes clearer. If you can come back to the same app, pick the new period, run the same tested process, and review the new output, you have changed the shape of the work. The accountant is no longer rebuilding the analysis from scratch. They are operating a system.
Where Slack fits
We also enabled Slack during the build because the workflow does not have to live only inside the app.
A common version of this use case is asking, late in the month, “How much are we expecting in PO accruals this month?” You might want that answer before the formal close process starts, especially if you are trying to understand the impact on OpEx.
The right system should be able to support both modes. When you are closing, you need the controlled dashboard, the run history, the review screen, and the journal entry path. When you are checking status mid-month, you may want to ask from Slack and get a quick answer backed by the same underlying workflow. That is what I mean by building around the way finance work actually happens.
What I want people to take away
The best AI finance workflows do not feel like generic chatbots. They feel like the spreadsheet, the checklist, the report, the review queue, and the system integration were finally rebuilt as one workflow.
That is what we are building toward with Lumera. Start with a process your team already knows well: accruals, reconciliations, reporting, close packets, vendor follow-up, flux analysis. Then map the real workflow. What data comes in? What logic gets applied? Where does judgment matter? Who needs to review it? Where does the final output go?
If you can answer those questions, you are much closer to building a useful AI finance app than you might think.
Join me next week at Lumera Live
Lumera Live is a weekly office hours series for finance and accounting teams who want to put AI to work in real workflows.
Each session starts with a live demo of an AI-powered finance workflow on Lumera, followed by open AMA. Bring a question or an automation idea you are trying to think through.
We will cover practical ways to use AI across close, reconciliations, reporting, FP&A, and NetSuite workflows.
Register for free: luma.com/lumera
Sowmya is the CEO and co-founder of Lumera, AI infrastructure for finance teams. She was previously Controller at OpenAI and Rippling, and led Corporate Accounting at Square.