What Ten Finance Teams Learned by Building with AI for the Close

Samuel Van Innis · · 5 min read

Key Takeaways

  • Ten finance teams spent a day building AI for their own work, from remittance matching to chasing late payments to treasury forecasting and intercompany reconciliation.
  • Getting something to work was the easy part.
  • The hard part was everything around the build: picking a small enough problem, making it cheap enough to run at volume, and getting the data clean enough to trust.
  • Every finance team hits these same questions the moment they try to take an AI idea all the way to closing day.

On 26 May 2026 we helped run the AI Finance Hackathon in Ghent, together with Spott, McKinsey, Finhouse and Smartfin. Ten finance teams showed up and spent the day building AI for their own work. We watched all of it. Here is what we learned.


Ten finance teams, one day

Some teams came in with a sharp problem and left with something that worked. Others spent the day figuring out what the problem even was, and left with a better question than they came with. Both are wins. Building something teaches you what is possible. Rethinking the problem teaches you what is worth building.

In the room: 9altitudes, Aikido, Copus, Guardsquare, House of HR, In The Pocket, Lighthouse, Mint, Pluxee, and Telenet.


A few of the things teams built

The point of the day was not really the leaderboard. It was seeing what a finance team could get working in a few hours. Here are some of the use cases, without saying who built what.

Remittance matching. One team gets 5,000 to 6,000 payments a month, and only about 73% match to an invoice on their own. The other 1,300 or so get sorted by hand, around 7 minutes each, jumping between Salesforce and NetSuite to work out which payment covers which invoice. That is most of a full-time job. They built an agent that does the digging and proposes each match, so the operator reviews a list and clicks approve. On approval it applies the payment in NetSuite and closes the case in Salesforce. The plan from here: keep a person on the uncertain ones, and auto-apply anything above 99% confidence.

Chasing late payments. Another team sends more than 100,000 invoices a month. They collect well, but some customers pay late, and while the contracts allow late fees, nobody had ever built the process to actually charge them. In a day they built a tool that reads the collection data, works out the fees and interest, and produces the upload file for the ERP, with the rules easy to change and an audit trail built in. On the day it found 650 invoices to bill, worth 40,000 to 42,000 euros that was quietly going uncollected.

Treasury reporting. A third team did their treasury reporting by hand in Excel every month. They built something that pulls the numbers out of NetSuite and produces a three to six month cash forecast, split by currency and entity, off historical trends.

Intercompany reconciliation. A fourth took on monthly intercompany matching across the P&L and the balance sheet, with the file for their consolidation tool prepared automatically. It is one of those jobs that eats days every close and only gets worse as you add entities.


The prototype was the easy part

Here is the thing that surprised people. Getting something to work was the easy part.

The building was real work, but it was not the hard part. The tools are good now. Most teams that decided to build had something running by mid-afternoon. The hard conversations were not about the code. They were about everything around it. Three questions kept coming up.


The three questions that actually mattered

Picking the right problem

The teams that got furthest picked a small problem first. The ones that stayed broad spent the day arguing about edge cases. AI does not paper over a vague brief. If you cannot say what a good answer looks like for one transaction, the agent cannot either.

Making it cheap enough to run at volume

Something that works on twenty invoices can fall apart on twenty thousand. What does each run cost? How fast is it? Does it hold up when you throw a real month at it? These are not details to sort out later. They decide whether it is worth running at all, every month, on every entity, on every line.

Data the model can actually trust

A model is only as good as what you feed it. Feed it bad data and it will give you a wrong answer, confidently. One team spent the afternoon building an agent, then realised the journal entries they were feeding it had the wrong analytical dimensions, or none at all. A cost centre missing here, a wrong project code there. The agent had nothing solid to work with. The fix was not a better model or a smarter prompt. It was going back and fixing the data. That is where most of the real day went, for more than one team, long after the prototype was running.


Why the close makes this harder

Most AI in finance today happens away from the close. A late-2025 McKinsey study found only 44% of finance teams have gone past experimenting and actually put AI into their core work. The rest of the close is still done by hand: keying in data, sorting transactions, tying out numbers.

The close is where those three questions get hard. There is no room on closing day for a run that costs too much or an answer that is wrong. The data has to be right. The volume has to clear. And the agent has to stay narrow enough that a controller can check what it did.


How we think about it at Eagl

This is what we build at Eagl. AI agents for the month-end close, on top of NetSuite, Microsoft Dynamics 365 Business Central and Exact Online. Three of our early decisions came straight out of the questions above:

  • It works inside your ERP. Right there in NetSuite, Microsoft Dynamics 365 Business Central or Exact Online. No exporting to a spreadsheet and hoping. It reads and posts where your numbers already are.
  • It learns how your books work. That Vendor X always goes to cost centre 500. That the insurance premium spreads over twelve months. That this intercompany flow nets out that way. It remembers, per company, and uses it every close. So the knowledge does not leave when a person does.
  • It fixes things, and shows its work. When it finds an error it writes the journal entry and posts it once you approve, with a record of what changed and why. Not a spreadsheet you type in again by hand.

We were never trying to build a prototype. We were trying to build a close that runs every month.


The part your auditor asks about first

Here is what actually keeps finance leaders up at night. It is not whether the agent can do the work. It is whether it will be wrong on the one entity that matters, and you will sign off without noticing.

So nothing posts by itself. The agent proposes, a person approves. And the person approving is not the agent that proposed it, so segregation of duties holds. Everything it does is logged, with the reasoning and the before and after. The audit trail is not a report you build later. It is just how the work happens. And when the auditor asks who is responsible, the answer is the same as always: whoever signed off.

The agent is not there to take away your judgment. It is there to make sure that by the time something reaches you, it has already been checked, line by line.


FAQ

Why do most AI projects stall after the prototype?

Because the prototype only proves it can work. Going live proves it clears the real bar: scope, cost, and clean data. Most people underestimate that second test. McKinsey found the teams getting the most out of AI spend three times more on redesigning how they work than on the software itself. The build is rarely where it is won or lost.

What kinds of finance problems suit AI agents?

Repetitive work with clear inputs and outputs, and enough volume to be worth it. Reconciliation, accruals, variance commentary, close management. Those are good places to start.

How long does it take to go from prototype to production?

It depends, but rarely weeks. The hold-up is usually the data and the scope, not the model. Measure the payback in terms you already use: hours your team gets back from reconciling and re-keying by hand, and days off the close. A well-scoped agent should be doing real work by the first close it runs, not after a quarter of setup.


What this means for your next close

If you are figuring out where AI fits in your close, start small. Pick the spot with the lowest risk and the highest volume. One reconciliation. One entity. One check you already do every month. Keep it narrow, run it on real volume to see what it costs, and make sure a controller can check the output and sign it. That is the whole path from a prototype to something that runs.

Want to see it on NetSuite, Microsoft Dynamics 365 Business Central or Exact Online? Request a demo and we will walk through it against your close, not a generic one.


Sources

About Eagl

Eagl is an agentic close management platform for high-volume, multi-entity finance teams, built to become the financial operating system for the office of the CFO. It runs account reconciliation, accrual management, and financial controlling on a data-quality layer that corrects errors as it automates, so output stays auditable. Finance teams including Reneo, Bluecrux, and Upvest rely on Eagl to close faster across multiple entities and currencies without sacrificing control.

Ready to see it in action?

Discover how Eagl transforms your financial operations with a personalized demo.

Request demo