# Oracle Fusion General Ledger: Import Journals errors and rejected rows > Source: https://netray.co/erp-help/fusion-general-ledger-import-journals-errors-gl-interface > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System oracle-fusion ## Erp Oracle Fusion Cloud ERP ## Module General Ledger / Journal Import ## Query Oracle Fusion General Ledger Import Journals errors GL_INTERFACE how to correct ## Alternate Queries - Fusion GL journal import error status - Import Journals no journals created Fusion - correct journal import errors Fusion ADFdi - Fusion journal source not defined import ## Applies To Oracle Fusion Cloud General Ledger with FBDI journal import and subledger-fed journals ## Steps ### Find and correct journal import errors **Items:** - Check the Import Journals scheduled process output and the Journal Import Execution Report for the source and group ID. - Note 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. - Confirm the Journal Source exists in Manage Journal Sources and that the import options (such as Import Descriptive Flexfields) match the file. - Confirm the ledger, currency and accounting date; the date must fall in an open or future-enterable period for that ledger. - Validate each account combination: active segment values, allowed postings, cross-validation rules and a valid balancing segment. - For multi-currency rows, check the currency conversion type and rate for the accounting date. - Correct the rows using the Correct Import Errors tooling or fix the source file and reload through the FBDI process, then rerun Import Journals. - Verify the batch in Journals > Manage Journals, and post it if posting is not automatic. ## Sections ### How journal import behaves **Body:** 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 **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Where do rejected journal rows go? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms Import Journals Fusion, GL_INTERFACE Fusion Cloud, journal import error Oracle Fusion, Fusion GL FBDI journal, correct journal import errors, Manage Journal Sources, Fusion accounting period closed error, Oracle Fusion General Ledger --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json