S Shortlisted
Home / Troubleshooting / Cost Processor Errors / this error
Oracle Fusion Cost Management · cost processor error · cause and fix

The transaction period is closed for General Ledger

Two calendars must agree before anything books: costing's calendar AND the General Ledger's. Here costing's month is open but GL's is shut, classic with backdated transactions (say it's March, someone entered a January transaction, and January is long closed in GL). Left alone this becomes a genuine deadlock: costing can't close its month because a transaction is pending, and the transaction can't process because GL is shut.

Root cause

Costing period open, GL period closed, the transaction is caught between two calendars.

How to fix it
  1. Break the deadlock deliberately: close the COSTING period, choosing to IGNORE the pending-transaction validation when it warns you
  2. That close sweeps the stuck transactions forward into the next open costing month; their GL date follows automatically
  3. Rerun the processor, everything books into the current open month
  4. Adopt the house rule that prevents this forever: always close subledger periods (costing) BEFORE closing the matching GL period
Where to go in Fusion
Oracle references

My Oracle Support document IDs for readers with access: 1304094.1. We do not reproduce their content.

Checked Cost processor behavior for Oracle Fusion Cost Management, rewritten in plain words from publicly known troubleshooting practice and reviewed by a working consultant. Checked against the current release, Jul 2026. Amounts, account names and navigation vary by configuration; verify in your own instance and test before acting.

Solve it, then prevent it

This page explains one error. These help with the rest:

🔧Search any cost processor errorThe interactive triage: paste your error, get the card.→🧾The setup behind these errorsThe Cost Management implementation guide.→✅Close without surprisesThe dependency-ordered SCM period close checklist.→
More cost processor errors