How JD Edwards EnterpriseOne resolves every G/L account from one Automatic Accounting Instructions table (F0012) keyed by company, document type and G/L class, how the Business Unit.Object.Subsidiary account key and the Subledger/Subledger Type pair carry operational detail, and how that single-table model maps onto D365's dozen posting-profile surfaces — including a fully traced inventory receipt.
Open the Automatic Accounting Instructions program in JD Edwards EnterpriseOne and you are looking at the entire accounting brain of the system in one grid: a short mnemonic in the left column, a resolved Business Unit.Object.Subsidiary account key in the right columns, and a handful of qualifying fields — company, document type, G/L…
An AAI item is a short code — some purely alphabetic (ICH), some numeric-prefixed by module (4310, 4320), a handful reserved for specific financial roles (RC, PC, GLG4) — that answers one question: for this kind of accounting event, which account does the money go to.
F0012 is a single table, but it is not a single kind of content. Financial AAIs answer questions general accounting asks on its own account — retained earnings, default trade receivables and payables.
Where many source ERPs push account selection down into individual records — a price list line, a customer field, an item attribute — JD Edwards does the opposite: almost the entire account-determination estate is concentrated in one physical table, addressed by a short key. D365 inverts that concentration.
Almost everything a JDE user enters — a journal entry, a voucher, an invoice, even the G/L side of a distribution transaction — is written first to an unposted batch. The batch header table, F0011, carries one row per batch: a batch number, a batch type (G for general accounting journal entries, V for A/P vouchers, I for A/R invoices,…
Every line on the Account Ledger table, F0911, carries two further fields beyond the account key itself: Subledger (SBL), a free-form value, and Subledger Type (SBLT), a code that tells the system what kind of value the Subledger field actually holds.
Every AAI-driven posting in JDE is really two entries: the one the operational transaction is obviously about, and an automatic offset the system derives without asking anyone. A purchase order receipt debits inventory (4310) and automatically credits the accrual account (4320) in the same action; nobody keys the offset side.
The table below traces a single purchase order receipt of 100 units of a finished-goods item at a standard cost of 15.00 per unit through both systems, from source transaction to posted (or posting-eligible) ledger entry.
JD Edwards concentrates account determination into one physical table addressed by a short mnemonic key; D365 distributes the same responsibility across a dozen purpose-built posting-profile surfaces. That inversion — not any difference in underlying complexity — is what makes this the defining workstream of a JDE programme.