JD EDWARDS SECURITY
How to Prevent AI Agents Creating Unauthorised Journal Entries, Payments, Supplier Changes or Purchase Orders in JD Edwards
The agent cannot perform most of these actions at all, and a named person approves the rest before anything reaches your ledger.
- Design for capability rather than conduct. The agent should be unable to do most things, not merely told not to.
- Four transaction types carry the highest risk: journal entries, payments, supplier master changes and purchase orders.
- Supplier bank detail changes deserve the strictest treatment of all, because they are the most common route to significant loss.
- Payment execution is the one capability we would keep off the list entirely, regardless of approval design.
- ChatFin proposes and never posts, calls only whitelisted orchestrations, and enforces named approval within your existing authority design.
This question comes from the right instinct. These four transaction types are where financial loss enters an organisation, and the arrival of a new actor that can create them deserves serious scrutiny.
The reassuring part is that the answer does not depend on trusting the model. It depends on architecture, and the architecture is straightforward.
The Layered Design
Five layers, each independently sufficient to prevent an unauthorised transaction, so no single failure is enough. This is what allows a confident answer to internal audit rather than a reassuring one.
Never let it post unseen
The failure worth designing against is not a dramatic one. It is small automated postings accumulating unreviewed until a balance makes no sense at month end.
Do not get to the point where these things are automatically posting and nobody's reviewing it, and you get to the end of the month and you're like, why is depreciation $10 million?
Chris Ortega, on the AgentCFO podcast
The layered design below puts a person between every draft and the ledger. That checkpoint is cheap next to a restatement.
Journal Entries
The most commonly requested write capability and a reasonable one, because accrual and reclassification work is a large part of what consumes a close.
Control it by scope rather than by prohibition. A dedicated posting orchestration, restricted account ranges, value thresholds, and a rule that any entry the agent proposes carries the source rows that justify it.
Payments: The One to Leave Out
Our position here is deliberately conservative and we would recommend it even to buyers evaluating someone else. Payment execution should not be on the agent's list of permitted actions at all.
The reason is asymmetry. The benefit of automating the final payment step is small, because the work was in the approval and the matching that preceded it. The consequence of an error is money leaving the organisation irrecoverably. That trade is not worth making regardless of how good the approval design is.
Supplier Master Changes
This deserves the strictest treatment of any item on the list. Changing a supplier bank account is the single most effective route to significant loss in most organisations, and it is the target of the most common fraud against finance functions.
Our recommendation is that the agent should never modify supplier bank details under any approval design. It can detect a change request, verify it against history, flag anomalies and route it, and the change itself should remain an entirely human process with its own verification.
Purchase Orders
Orders commit the organisation to spend, so the treatment sits between journal entries and payments. Drafting is valuable and creation should follow the same authority design you already apply to buyers.
The key requirement is that creation runs through a supported orchestration so pricing, tax, account derivation, commitment tracking and approval routing behave exactly as they would for a keyed order.
Segregation of Duties
A frequent concern is that an agent collapses segregation by performing steps that were deliberately separated. It does not, provided it inherits a single user's role.
Because the agent operates within the requesting person's entitlements, it cannot perform a combination that person could not perform. It cannot raise and approve, and it cannot reach a company or account outside their scope.
"Payment execution is the one capability we would leave off the list. The benefit is small and the failure is irreversible."
Monitoring the Agent Itself
The final layer treats the agent as an actor to be monitored like any other, which is both good practice and an easy answer to give a reviewer.
Unusual proposal patterns, activity outside normal hours, repeated attempts at actions that are not permitted, and a rising rate of rejected proposals are all signals worth surfacing.
Make It Impossible, Not Discouraged
ChatFin proposes and never posts, calls only whitelisted orchestrations, operates within the requesting user's role, and enforces named approval within your existing authority design, with supplier bank changes and payment execution excluded entirely.
The right answer is not that the agent was instructed carefully. It is that the action was never possible.
Frequently Asked Questions
How do you stop an AI agent creating unauthorised transactions in JD Edwards?
Through layered design rather than instruction. The agent can only call whitelisted orchestrations, so anything absent is impossible rather than discouraged. It operates within one user's role and cannot exceed what that person could do. Nothing posts without a named approval. Thresholds mirror your existing authority design. And every action is logged with anomalous patterns surfaced.
Should an AI agent be able to execute payments?
Our recommendation is no, and we would give the same advice to someone evaluating a different vendor. The benefit of automating the final payment step is small because the work was in the matching and approval that preceded it, while the consequence of an error is money leaving the organisation irrecoverably. Selecting and grouping items for a payment run is reasonable; releasing the run is not.
What about supplier bank detail changes?
These deserve the strictest treatment of anything on the list, because changing supplier bank details is the single most effective route to significant loss and the target of the most common fraud against finance functions. The agent should never modify them under any approval design. Its value is on the detection side: monitoring change requests for anomalies and routing them for independent human verification.