Journals, the trail of what people changed
Loads bring what the ledgers said; journals are what people decided to change. The journals list is the close's conscience, and the last screen worth reading before anything locks.
Fourth page on the reports shelf of the FCCS reference. Where journal amounts live in the cube is the Data Source dimension's question, the lock order belongs to Consolidation Status, and the whole reference is mapped on the FCCS index.
◆ The lifecycle— the statuses a journal walks through, and the rules the walk enforces.
| Rule | What it means in practice |
|---|---|
| Same word as the ledger's journals, different layer | The ERP's journal entries are the books of entry, business transactions posted by the thousand every day, most of them fed by subledgers. A consolidation journal is a different animal: a top-side adjustment, made by a person, on top of trial balances already loaded, and a close sees dozens, not thousands. The ledger side of the trail lives in our Oracle Fusion general ledger catalog, and the complete audit answer is both lists together, what the business posted, then what the close adjusted. |
| The walk is Working, Submitted, Approved, Posted | With workflow on, every stage happens in order, and skipping one, submitted straight to posted, errors out. Without workflow, a journal simply posts or unposts. Either way, only posting moves the number. |
| Journals land in their own member | Posted amounts live in the journal input member of the Data Source dimension, apart from loads forever. That separation is why the auditor's what-did-people-change question is a filter, not a project. |
| Viewers see posted only | A view-level user sees posted journals and nothing else, so the working drafts of close week stay out of sight until they are real. Re-posting after an unpost belongs to the submitter or an administrator. |
| Referenced members cannot be deleted | Metadata cleanup fails against members a journal references, by design. The error during a hierarchy tidy-up is usually an old journal holding on, and the journal list by member finds it. |
◆ Auto-reversing journals, the exact rules— the accrual machinery, verified against the current documentation.
| Rule | Why it matters |
|---|---|
| Posting creates next period's reversal | An auto-reversing journal, posted, writes its own undo into the following period. The accrual books itself out, which is the entire appeal. |
| The reversal cannot be edited | System-generated, it posts or unposts, nothing else. Unposting it returns it to Approved, waiting. |
| Unposting the original deletes the generated reversal | Kill the accrual before its reversal posts and the machinery cleans up after itself. But once the reversal has posted, the original cannot be unposted, and the pair now unwinds in order, reversal first, then original. |
| Year-end respect | The pair spans a period boundary, so December accruals reverse into a new year. Lock order and journal order meet exactly here, and the review before year-end lock is where the meeting goes well or badly. |
◆ Two stuck journals from the field— real cases from the forums, and what each teaches.
| Case | The lesson |
|---|---|
| Not authorized, on posting the reversal | The reversal posts into a different period than its original, so permissions that covered January do not automatically cover February. When an auto-reversal refuses to post, check the posting user's rights against the reversal's period and entities, not the original's. |
| The journal that cannot be unposted or deleted | A journal written against a top-level entity and a child entity together, and the application refuses to release it, reporting that different entities cannot mix once a top-level member is in. The prevention is the lesson: one entity level per journal, and adjustments at parents kept to the parent-only members. Trapped ones become a support conversation. |
The close discipline that falls out of all of this: the journal review before lock reads three lists, everything unposted, everything auto-reversing that spans the boundary, and everything posted this period with its attachment trail, because journal actions carry attachments and that trail is the audit answer. In the owned warehouse, the star schema we recommend building beside FCCS on your own cloud, mapped here, journals land as their own source rows, so adjustment analysis by entity, account, and approver is a standing query. Lifecycle, auto-reverse rules, and both cases verified against Oracle's documentation and Customer Connect, July 2026.
- Working
- A draft. Moves nothing, shows to no viewer, blocks the lock.
- journal input
- The Data Source member where posted adjustments live, apart from loads.
- auto-reversal
- The system-written undo in the next period. Posts or unposts, never edits.
- the review before lock
- Unposted, boundary-spanning, and posted-with-trail. Three lists, then lock.