JD EDWARDS AI
Can an AI Agent Securely Query JD Edwards Tables F0911, F0411, F4311 and F4211?
Yes, and the path matters more than the answer. One route keeps JD Edwards security in force and the other removes it.
- F0911 is the Account Ledger, F0411 the Accounts Payable Ledger, F03B11 the Customer Ledger for receivables, F4311 Purchase Order Detail and F4211 Sales Order Detail.
- Query through the AIS data service or a published orchestration so the session carries a real username, environment and role, and visibility follows your existing design.
- A dedicated read orchestration with parameters is safer than exposing arbitrary query capability, because the permitted surface is explicit and reviewable.
- Read access does not imply write access. Separate the identities, separate the whitelists, and never let an analytical path reach a posting orchestration.
- ChatFin queries these tables through controlled orchestrations, returns the rows behind every figure, and logs each call with the requester and the parameters used.
This question usually arrives from an IT team that has been asked to approve an AI project and wants to know what the agent will touch. It is the right question, and the honest answer is that the tables are not the risk. The access path is.
The same query against F0911 can be entirely safe or a governance failure depending on whether it ran inside a JD Edwards session or through a database account with a static password in a configuration file.
F0911
F0411
F03B11
F4311
F4211
Data Service
Whitelisted Reads
What These Tables Hold
A brief orientation, because the table numbers are frequently cited and less frequently explained. Note that receivables invoices sit in F03B11 rather than the number often assumed.
F0911 Account Ledger: General ledger transaction detail. The source for account movement, variance work and the comparisons behind integrity reporting.
F0411 Accounts Payable Ledger: Supplier voucher detail. Payments are separate, sitting in the payment header and detail tables, which is why voucher and payment analysis must be handled distinctly.
F03B11 Customer Ledger: Receivables invoice detail, with receipts held separately in their own header and detail tables.
F4311 and F4211: Purchase Order Detail and Sales Order Detail, the operational lines behind commitments, receipts, shipments and the margin analysis finance rarely gets to see.
Three Access Paths, Ranked
There are three realistic ways an agent can read these tables, and they are not equivalent from a control standpoint even though they can return identical rows.
Published orchestration: The strongest option. A named, parameterised read service that appears on a whitelist. The permitted surface is explicit and easy for internal audit to review.
AIS data service: Direct queries against tables and business views inside an authenticated session, with aggregation and paging. Flexible and still inside the security model.
Database replica: Acceptable for heavy analytics on a copy, with the understanding that JD Edwards role security does not apply there and access control becomes a database problem.
Production database account: Not acceptable. It bypasses the security model entirely, attributes every action to one identity, and puts a write capable credential in reach of a query path.
Why a Parameterised Read Service Beats Open Query
The tempting design is a general query tool that accepts arbitrary selection criteria, because it can answer anything. The cost is that it can also do anything, and nobody can describe its boundaries in a control document.
A parameterised service inverts that. Open payables by supplier and period, ledger detail for an account range, purchase order lines received but not vouchered. Each is a defined service with typed inputs, and the complete list of what the agent may read fits on one page.
Reviewable: Internal audit can read the list of services and understand the exposure without reading code.
Testable: Fixed inputs and predictable outputs, so regression testing after a Tools Release is straightforward.
Bounded: No path to a table the service was not designed to reach, regardless of what is requested.
Logged meaningfully: The log records which business question was asked rather than an opaque query string.
Separating Read From Write
The most important control in the whole design is that reading and writing are different capabilities with different identities. An analytical agent should be structurally incapable of creating a transaction, not merely instructed not to.
In practice this means separate credentials, separate whitelists and separate logging streams. It also means that adding a write capability is a deliberate decision with its own approval, rather than something that arrives as a side effect of an integration change.
Distinct identities: The read path and the write path do not share credentials, so a compromise of one does not become a compromise of both.
Distinct whitelists: Read services and posting orchestrations are separately maintained lists with separate change control.
Explicit escalation: Enabling a write capability is a documented decision, not a configuration default.
Separate logs: Query activity and transaction activity are reviewed by different people for different reasons.
Performance and the Replica Decision
Analytical queries against F0911 or F4211 can be large, and running them against a busy production instance is a legitimate operational concern that IT will raise early. The answer is usually a split.
Operational questions that lead to immediate action read live, because a stale open balance is worse than a slow one. Broad analytical passes run against a replica where latency of a few hours is acceptable. What matters is that the answer states which source it used and when the data was read, so nobody acts on last night's figure during close.
Aggregate at source: Use the data service aggregation rather than pulling rows into the agent to be summed.
Page large sets: Fetch in chunks rather than requesting everything, which also protects the agent's own reliability.
Cap result size: A maximum row count protects production and improves question quality.
State the source: Every answer carries whether it came from live or replica and the time it was read.
What Internal Audit Will Ask
The review is predictable and short if the design is right, because each question maps to something you can show.
Who can query what: Show the whitelist of read services and the role design behind the session.
How is access evidenced: Show the log: requester, service, parameters, rows returned and time.
Can it write: Show that the read identity has no path to a posting orchestration.
What happens on a Tools Release: Show the inventory of endpoints and orchestrations and the replay evidence from the test environment.
"The table is not the risk. A read against F0911 inside an authenticated session and the same read through a database password are entirely different events."
How ChatFin Reads JD Edwards
ChatFin reads through controlled orchestrations and the AIS data service inside an authenticated session, so ledger, payables, receivables, purchase order and sales order data is visible only to the extent the requester's role allows. Every figure returned carries the rows behind it, and every call is logged with the requester, the parameters and the time.
The read path is separate from the posting path by design. Analytical work cannot create a transaction, and enabling a write capability is a deliberate, documented step with its own approval.
Query the Ledger Without Loosening the Controls
ChatFin queries F0911, F0411, F03B11, F4311, F4211 and the rest of your JD Edwards data through authenticated sessions and whitelisted services, returns the supporting rows with every answer, and keeps read access structurally separate from any ability to post.
Same rows, different governance. The access path is the control, not the table.
Why the query path matters more than the query
These four tables hold most of what finance asks about, and there are two ways to read them.
Direct database access. Fast to build and wrong for production. It bypasses JD Edwards row and column security entirely, so the agent sees everything the database user sees rather than everything the requesting person is entitled to see.
AIS and orchestrations. The request arrives as a JD Edwards user and JDE applies its own security. The agent cannot read a company or business unit the person is not entitled to.
Performance is a real constraint. F0911 degrades as it grows. Practitioners report partitioning by GL date running several times faster on date filtered queries, and fetches that take hours from the application returning in about a minute from a SQL worksheet. Scope the query before blaming the model.
F4211 and F4311 need joins. Sales and purchase order detail rarely answer a question alone. They have to be read alongside the receiver file and the AP ledger, which is what One View cannot do outside its own business view.
Frequently Asked Questions
Can an AI agent query F0911, F0411, F4311 and F4211 securely?
Yes, provided it queries through the AIS data service or a published orchestration inside an authenticated session rather than through a database account. That way the session carries a real username, environment and role, so visibility follows your existing JD Edwards security design and every call can be attributed to the person who asked.
Which table holds accounts receivable invoices?
F03B11, the Customer Ledger, holds receivables invoice detail. Receipts sit separately in their own header and detail tables, in the same way that payables vouchers in F0411 are distinct from payment records. Treating invoices and receipts as one dataset is a common cause of double counting.
Should the agent read from production or a replica?
Split it. Operational questions where someone will act immediately should read live, because a stale open balance is worse than a slow one. Broad analytical passes can run against a replica where a few hours of latency is acceptable. Either way the answer should state which source it used and when the data was read.
Related Articles