An AI agent prepares a journal entry, sends it to the ERP, and produces the expected results in testing. The project team demonstrates the solution, documents the integration, and schedules the launch.
Then someone asks a question that should have been answered at the beginning. “Who owns this process once it’s live?”
Finance expects IT to keep the agent running. IT expects Finance to review the results. The developer is ready to move to the next assignment. Everyone has a role, but no one has clearly accepted responsibility for the entire process.
This is where an AI implementation requires more than a technical handoff. An agent connected to an ERP becomes part of a business process. Someone must own the output, approve changes, resolve exceptions, and decide what happens if/when the process fails. Below is a framework for determining who owns what after the agent is built.
“IT will support it” is not a complete operating model. IT can monitor an integration, manage access, and investigate a failed connection. However, those responsibilities do not make IT accountable for whether a journal entry reflects the correct accounting treatment.
Finance must own the accounting outcome. That includes approving calculation rules, validating results, reconciling entries, and deciding how to handle exceptions. Developers can address defects and enhance the solution, but they should not be the default decision-makers for accounting questions.
Consider an agent that prepares a work-in-progress journal entry. If the agent runs successfully but uses an outdated calculation rule, the technical process may be working exactly as designed, but the accounting result is still wrong.
Clear ownership separates these responsibilities:
One person may hold more than one role. The important point is that the responsibilities are explicit. A shared responsibility should not become an unassigned responsibility.
A successful demonstration proves that a solution can work under the conditions shown. Production acceptance requires more. For an ERP-connected agent, the team should validate both execution and results. Did the agent complete its task? Did it use the right inputs? Is the output accurate? Can the reviewer explain and reconcile it?
Testing should include conditions beyond a clean set of sample data:
The team also needs to define the agent’s authority. Preparing a draft entry, submitting an entry for approval, and posting directly to the ERP are different operating decisions. Each requires its own controls and acceptance criteria. Before launch, the business owner should approve the results and the operating procedures. The evidence should be retained so the team can distinguish what was tested from what was assumed.
“Ready for production” should mean the business can operate the process, not just that the developer can demonstrate it.
A technical diagram might explain how the agent connects to the ERP, but it might not tell a controller what to do when an entry fails during close. The handoff package should serve the people who will operate and support the process. It should answer practical questions without requiring them to reconstruct the developer’s work.
At a minimum, it should document the following:
Test the package along with the solution. Someone other than the original developer should be able to follow the instructions, identify an exception, and determine the next step.
Imagine the WIP agent fails during month-end close. It prepared an entry, but the team can’t tell if the ERP accepted it. Running the agent again could resolve the issue… or create a duplicate. Before anyone restarts the agent, the team needs to find out what actually happened. The operating procedure should define who checks the ERP, who reconciles the results, and who authorizes the next action. Technical support can investigate the failed connection while Finance determines if the accounting activity is complete.
If the automated process can’t be restored in time, the business owner needs a clear fallback. Finance may need to prepare the entry manually. Before automation resumes, the team must account for that manual work so the agent doesn’t process it again.
These decisions should not be improvised during close. Before go-live, agree on:
Not every failure requires the same response. A connection timeout is different from an incorrect calculation. The support model must distinguish between repairing the tool and correcting the business outcome.
An agent can remain technically functional while the business around it changes. Finance adds a department. The chart of accounts changes. A source report uses a new format. The ERP configuration is updated. A calculation rule that was appropriate at launch no longer reflects the approved accounting approach. These changes need an owner and a review process. Changes to accounting logic should require Finance approval. Technical updates should be tested before release. Changes to source data or ERP configuration should trigger a review of the affected dependencies.
The team should also retain a record of what changed, who approved it, and how it was validated. When a result looks different from the prior month, users need to know whether the difference came from the underlying business activity or a change to the solution.
The original developer shouldn’t be the only person who understands how the process works. Ownership must continue after the implementation team moves on.
The best time to assign ownership is when the process is being designed. That’s when the team can establish approval requirements, define acceptance criteria, and build support procedures into the solution. Waiting until the final project meeting creates a different conversation around who is willing to take responsibility for something already built.
An AI-to-ERP implementation should deliver more than a working agent and a functioning connection. It should deliver a process the business can validate, operate, support, and change.
Before calling the project complete, ask one question: If this process fails during month-end close, does everyone know who makes the decision and what happens next? If the answer is unclear, the handoff is not finished.
At Trenegy, we help organizations deploy AI and ERP solutions the business can own, operate, and support long after we leave. To chat more about this, emailinfo@trenegy.com.
Trenegy is a non-traditional consulting firm based in Houston, Texas.
