Oracle Fusion General Ledger: Import Journals errors and rejected rows
Oracle Fusion General Ledger Import Journals errors GL_INTERFACE how to correct
Also searched as
- Fusion GL journal import error status
- Import Journals no journals created Fusion
- correct journal import errors Fusion ADFdi
- Fusion journal source not defined import
Short answer
Import Journals loads rows from GL_INTERFACE into journal batches, and rows that fail validation stay in the interface with an error status. Check the journal source, ledger, accounting period, account combination and balancing, correct the rows through the correction tool or by reloading, and rerun Import Journals for the same source and group.
Applies to: Oracle Fusion Cloud General Ledger with FBDI journal import and subledger-fed journals
Find and correct journal import errors
- 1Check the Import Journals scheduled process output and the Journal Import Execution Report for the source and group ID.
- 2Note the status or error code on the rejected rows; each code maps to one validation failure such as an invalid account or a closed period.
- 3Confirm the Journal Source exists in Manage Journal Sources and that the import options (such as Import Descriptive Flexfields) match the file.
- 4Confirm the ledger, currency and accounting date; the date must fall in an open or future-enterable period for that ledger.
- 5Validate each account combination: active segment values, allowed postings, cross-validation rules and a valid balancing segment.
- 6For multi-currency rows, check the currency conversion type and rate for the accounting date.
- 7Correct the rows using the Correct Import Errors tooling or fix the source file and reload through the FBDI process, then rerun Import Journals.
- 8Verify the batch in Journals > Manage Journals, and post it if posting is not automatic.
How journal import behaves
Journal data arrives in the GL_INTERFACE table, whether it comes from an FBDI file, a subledger transfer or an integration. The Import Journals process validates each row and creates journals grouped by source, ledger, category, currency and accounting date. Rows that pass are consumed; rows that fail remain with a status code that names the reason.
Because journals must balance within each group, one rejected line can leave the import creating nothing for that group or creating an unbalanced candidate that fails balancing. Treat the group ID as the unit of work, and keep it consistent between the load and the import so a rerun targets exactly the same rows.
Frequent root causes
Closed or never-opened period. The accounting date falls in a period that is Closed, Permanently Closed or Never Opened. Either reopen the period under controlled approval or change the accounting date. Backdating into a closed period is a finance policy decision rather than a data fix.
Invalid account. The code combination is inactive, end-dated, fails cross-validation, or has a segment that does not allow posting. Dynamic insertion settings determine whether a new combination can be created on the fly; if it is off, the combination must exist first.
Source or category not defined. The journal source and category must exist and be enabled for the ledger. A new feeding system that was never registered will fail on every row.
Conversion rates. Foreign currency journals need a daily rate for the conversion type and date, or an explicit user rate on the row.
Unbalanced groups. Debits and credits differ, usually because of a dropped line in the upstream extract or rounding. Check totals per group before loading.
Correcting versus reloading
Small numbers of errors can be fixed in place through the spreadsheet-based correction tool, which lets you edit error rows and resubmit. For files produced by a system, reloading from corrected source is cleaner, because it keeps the source of truth consistent and avoids drift between the interface and the originating system.
Before reloading, remove or purge the failed rows if the old group ID will be reused, or load with a new group ID. Re-importing the same group with old rows still present is a classic way to double a journal. Reconcile control totals between the source extract and the posted batch after every correction.
Navigator > General Accounting > Journals > Import Journals Parameters: Data Access Set, Source, Ledger, Group ID, Import Descriptive Flexfields Navigator > Setup and Maintenance > Manage Journal Sources Navigator > General Accounting > Period Close > Manage Accounting Periods
Preventing repeat failures
Validate before you load. A pre-check against the chart of accounts and period status, run by the integration, removes the majority of rejects. Where the feeding system is under your control, add checks for balancing per group, valid segment values and period openness.
Monitor the interface. A small recurring report of rows older than a day in GL_INTERFACE with an error status, grouped by source, tells the close team about problems before the period-end rush.
Common pitfalls
- !Reusing a group ID without clearing failed rows, which can duplicate journals on rerun.
- !Reopening a closed period just to push a journal through, without finance approval.
- !Fixing the invalid account on one row while the same combination appears on hundreds.
- !Forgetting that dynamic insertion may be disabled, so new combinations are rejected.
- !Loading foreign currency rows without a conversion rate for the accounting date.
How an ERP-grounded AI assistant handles this
A grounded assistant such as ERPray can summarise the rows left in the interface by source, group and status, and tell the close team that, for example, most rejects are one end-dated cost center. It reads the data without writing and shows its query. Reopening periods, correcting rows and reimporting remain human actions with the usual approval.
Frequently asked questions
Where do rejected journal rows go?
They remain in the GL_INTERFACE table with a status code identifying the validation failure. The Journal Import Execution Report lists them per source and group ID. Correct or reload them, then rerun Import Journals for the same group.
Why were no journals created even though the file loaded?
Loading puts rows in the interface; Import Journals must still run and succeed. Common reasons for nothing created are a closed period, a source not defined for the ledger, an invalid account on every row, or the import being run with a different group ID.
Can I change the accounting date to get past a closed period?
Technically yes, but it changes the period in which the transaction is reported, so it is a finance decision. Get approval, document why, and prefer reopening a period only under your normal close controls.
How do I avoid duplicate journals when reimporting?
Use a new group ID for each corrected load or purge the failed rows from the interface first, and reconcile control totals between the source and posted batches afterwards. Do not rerun the same group with stale rows still in place.
Related
Oracle Fusion Period Close: A Practical Checklist
Closing a Fusion GL period cleanly means closing every feeder subledger first (Payables, Receivables, Costing, Fixed Assets), running Create Accounting to post everything to GL, reconciling subledger-to-GL balances, and only then setting the GL period status to Closed - not Close Pending, which still allows adjustments. Close Monitor gives a single dashboard of every subledger's close status instead of checking each module separately.
Error fixFix FBDI Import Failures From Interface Table Validation Errors
When a Fusion FBDI import job errors out, the cause is almost always bad data in the interface tables (an invalid value set, a wrong date format, or a missing required column), not the ESS job itself. Open the process's Interface Errors Report or the Correct Import Errors spreadsheet to see the exact rejected rows and reason codes, fix the source data, and resubmit from the interface tables instead of re-running the whole FBDI load.
Error fixOracle Fusion: Cost Accounting Distributions Not Created
When an inventory or work order transaction has no cost accounting distributions, it is almost always stuck before costing: the item or organization is not set up in a cost organization and cost book, the item has no cost to apply, or the cost processing and accounting scheduled processes have not picked it up. Work through setup first, then the transaction status, then the jobs.
Error fixClear An Oracle Fusion ESS Job Stuck In Blocked Status
A Blocked status on an Oracle Fusion Enterprise Scheduler (ESS) job almost always means an earlier instance of the exact same job is still running or stuck, and the job definition does not allow simultaneous requests. Find and finish, or cancel, the earlier request first; only then does the Blocked request move to Running.
How-toOTBI vs BI Publisher: Which One Should You Use
Use OTBI when a business user needs ad hoc, self-service, real-time analysis with no fixed layout. Use BI Publisher when you need a pixel-perfect, scheduled, high-volume, or externally distributed document such as an invoice, check, or statutory report. Most Fusion implementations end up using both, not one instead of the other.
How-toPaginate And Authenticate Oracle Fusion REST API Calls Correctly
Oracle Fusion Cloud REST APIs authenticate with HTTP Basic Authentication, an integration user's credentials, over HTTPS by default, and paginate with limit and offset query parameters rather than a page number. Loop on the hasMore flag in the response until it returns false to retrieve a full result set.
AI for ERPFusion Cloud ERP AI: OCI Generative AI Service vs. a Private LLM
Oracle's OCI Generative AI Service is a real option for Fusion Cloud ERP, but not the only one. Compare it honestly against a private LLM for sensitive data.
Stuck on Oracle Fusion Cloud ERP?
Talk to engineers who work inside Oracle Fusion Cloud ERP every week, and who build private AI that answers these questions from your own ERP data.