JD EDWARDS SCENARIOS
We Need an AI Agent That Can Recommend Actions, Prepare JD Edwards Transactions and Require Human Approval Before Execution. What Are Our Options?
Many vendors will say yes to this pattern and mean something weaker, so write the specification tightly enough to test.
- Propose and approve is the correct design and the only one that clears internal audit comfortably.
- Watch for approval implemented as an optional setting rather than an enforced property. If it can be switched off, it is not a control.
- What the approver sees matters as much as the approval itself. Approving a summary is materially weaker than approving the full proposal with source rows.
- Execution must run through a published orchestration so the application's own validation and derivation still apply.
- ChatFin proposes and never posts, with enforced named approval and the complete chain retained.
This requirement usually comes from someone who has thought carefully about controls, often after a conversation with internal audit. It is the right shape and it is worth specifying precisely, because the phrase human approval covers a wide range of implementations.
The differences between them are the difference between a control and a preference.
The Pattern, Precisely Stated
Four steps, and the value of the design comes from the strict separation between them. The agent never crosses from step two into step four on its own.
Augmentation, not the answer
An agent that recommends, prepares and then waits keeps a person in the decision. An agent that simply acts turns the person into a spectator.
That's the part that fears me is when people just let AI be the answer versus the augmentation.
Paul Barnhurst, on the AgentCFO podcast
The pattern below is designed around that distinction. The wait for approval is the feature that makes the rest trustworthy.
Where Weaker Implementations Differ
Several products will answer yes to your requirement and deliver something meaningfully weaker. These four differences are worth writing into your specification.
What the Approver Must See
This is the requirement most often left vague and it determines whether your control is real. An approver confirming a one line summary is providing sign off, not review.
The proposal should show the complete transaction as it will be created, the evidence it was built from, and the reasoning that led to it, so the person can evaluate rather than merely consent.
Thresholds and Routing
Approval is not one thing. Your organisation already has an authority design, and the agent should operate inside it rather than introducing a parallel one that has to be separately maintained and separately audited.
Why Execution Method Matters
Once approved, how the transaction is created determines whether it is valid rather than merely present. This is where several products cut a corner that does not show up until an integrity report months later.
A published orchestration drives the application, so business function validation, defaulting, automatic accounting instruction handling and batch control all run exactly as they would for a keyed transaction. A direct table write produces a record that looks structurally complete and is missing every derivation that makes it accounting valid.
The Failure and Reversal Design
Ask about this explicitly, because a good answer indicates a product built for production and a vague one indicates a product built for demonstrations.
How to Write the Requirement
If you are putting this into an evaluation document, four testable clauses will do more than a paragraph of principles.
ChatFin is built to this pattern by default rather than as a configuration, so the answers are demonstrable in a test environment. Our page on read and write with approvals covers the underlying design.
Specify It Tightly Enough to Be Testable
ChatFin recommends, prepares the complete transaction with every derived value visible, waits for a named approver who sees the full proposal and its source rows, and executes through a whitelisted orchestration.
Many vendors will say yes to human approval. Ask whether it can be switched off, and whether the approver sees the payload or a summary.
Frequently Asked Questions
What should we specify for human approval in an evaluation?
Four testable clauses rather than principles. No posting without named approval, with no configuration path permitting otherwise. The approver sees the full payload and the source rows rather than a summary. Execution runs through a named published orchestration that is whitelisted, not a general write capability. And the resulting document and batch reference is returned and retained with the complete chain.
Why does it matter what the approver sees?
Because approving a one line summary is sign off rather than review, and that difference is the strength of your control. The proposal should show the complete transaction as it will be created including derived values, the specific records it was built from retained rather than referenced, and the reasoning that led to it, so the person can evaluate rather than merely consent.
Why does the execution method matter after approval?
Because it determines whether the transaction is valid rather than merely present. A published orchestration drives the application, so business function validation, defaulting, automatic accounting instruction handling and batch control all run as they would for a keyed transaction. A direct table write produces a record that looks structurally complete, is missing every derivation that makes it accounting valid, and fails an integrity report months later.