Journal Source

 

Journal Source

  Journal Sources in Oracle Fusion Financials — What They Are and Why They Matter

 

  If you've spent any real time inside the General Ledger module of Oracle Fusion, you've bumped into the word "Source"

  more times than you can count. It shows up when you're reviewing journals, when you're running reconciliations, when

  you're setting up AutoPost rules, and especially when a client calls you in a panic asking "where did this entry come

  from?" The Journal Source is, quietly, one of the most useful pieces of metadata in the whole ledger. People tend to

  overlook it because it sits in the background and doesn't demand attention the way an account combination or a

  balancing segment does. But once you understand what it's really doing, a lot of the confusing behavior in GL starts

  to make sense.

 

  So let me walk through it the way I'd explain it to a new analyst sitting next to me — not from a manual, but from the

  way it actually works day to day.

 

  The simplest way to think about it

 

  A Journal Source answers one question, and it answers it for every single journal line that lands in your General

  Ledger: "Who or what created this entry?"

 

  That's genuinely it. The Source is a tag. It tells you the origin of the journal. Did it come from Payables? From

  Receivables? Did somebody key it in by hand? Did it flow over from a third-party payroll system through a spreadsheet

  upload? Did it come from Assets when depreciation ran? Each of those origins carries its own Source value, and that

  value rides along with the journal forever.

 

  Now, why does that matter so much? Because the General Ledger is the place where everything eventually meets. Think

  about it — your AP invoices, your customer receipts, your fixed asset depreciation, your manual accruals, your

  intercompany allocations, your payroll costing — all of it ends up posted to the same set of accounts in the same

  ledger. Without a Source tag, the GL would be one undifferentiated soup of debits and credits, and you'd have no idea

  which subledger or process was responsible for any given balance. The Source is what keeps that soup readable. It's

  the return address on the envelope.

 

  I often tell people the Source is half of a pair. The other half is the Category. Source tells you where the journal

  came from, and Category tells you what kind of transaction it represents. So you might have a journal with a Source of

  "Payables" and a Category of "Purchase Invoices," or a Source of "Receivables" with a Category of "Sales Invoices."

  Together they give you a two-dimensional way to slice and trace every entry. Source is the origin; Category is the

  nature. Keep those two straight in your head and you're already ahead of most users.

 

  Where you actually see the Source in the application

 

  Let me ground this in real navigation, because abstract definitions only get you so far.

 

  When you open the General Accounting work area and go into Journals, every journal you look at has a Source field

  right there on the journal header. Open any posted journal — say one that flowed in from the Payables subledger — and

  you'll see the Source reads "Payables." Open one that an accountant typed during the close, and you'll see "Manual"

  (or "Spreadsheet" if they used the ADFdi upload spreadsheet, which is the case more often than people realize).

 

  The Source also turns up in a lot of the inquiry and reporting screens. When you run the Journals Report or use the

  Account Inspector and drill into balances, you can pivot or filter by Source. In Smart View and in OTBI analyses,

  Source is one of the standard attributes you can drag onto a report. So when finance asks "of this $4.2 million

  sitting in the accrued liabilities account, how much came from Payables versus manual top-side entries?" — the Source

  is exactly the field that answers that. You filter the account activity by Source and the picture resolves

  immediately.

 

  It shows up in the close process too. When you're working through period close and you're trying to make sure all the

  subledgers have swept their data into GL, you're essentially checking that journals from each expected Source have

  arrived and posted. If the Payables Source journals haven't shown up yet, you know the transfer from AP hasn't

  completed and you're not ready to close.

 

  The seeded sources — the ones Oracle gives you out of the box

 

  Oracle ships Fusion with a healthy list of predefined Journal Sources, and these cover the standard subledgers and

  processes. You don't create these; they're there from day one and the system uses them automatically. The ones you'll

  run into constantly are:

 

  - Payables — anything coming from the AP subledger: invoices, payments, prepayments, the lot.

  - Receivables — invoices, receipts, adjustments, credit memos flowing from AR.

  - Assets — additions, depreciation, retirements, transfers from the Fixed Assets module.

  - Cost Management — inventory and costing entries in environments that run SCM alongside Financials.

  - Payroll — costing entries when payroll is integrated.

  - Manual — entries created directly by a person inside the GL Journals page.

  - Spreadsheet — entries brought in through the journal import spreadsheet (the ADFdi-based upload). A lot of people

  assume their uploaded entries are "Manual," and they're often surprised to learn they actually carry the "Spreadsheet"

  source. It's a useful distinction, because it lets you separate truly hand-keyed work from bulk-loaded work.

  - Revaluation, Translation, Allocation — these come from the period-end GL processes themselves. When you run a

  revaluation for foreign currency balances, the resulting journal carries the Revaluation source. Same logic for

  translation and for allocations generated by the Allocation Manager / Calculation Manager.

  - Balance Transfer and Closing Journals — used by the period-close and balance-carry-forward processes.

 

  The reason this seeded list matters is that the subledgers are hard-wired to stamp the correct Source when they

  transfer to GL. You don't configure that mapping in normal circumstances — Payables knows it's Payables. The plumbing

  is built in. Where you do get involved is when you're bringing data in from outside the Oracle suite, and that's where

  custom sources come into play.

 

  Creating your own Journal Sources

 

  Here's the scenario that comes up on almost every implementation. The client has some system that isn't part of Oracle

  — maybe a legacy billing platform, a bank feed, a third-party expense tool, a point-of-sale system, an external

  payroll bureau, whatever. They need to get accounting entries from that system into Fusion GL. The mechanism for that

  is Journal Import (the GL_INTERFACE / Import Journals flow), and when those external entries land, you want them

  tagged with a Source that clearly identifies them. You don't want them all dumped under "Spreadsheet" or "Manual,"

  because then you've lost the ability to distinguish them from genuine manual work.

 

  So you create a custom Journal Source. The navigation for this is through the Setup and Maintenance work area. You go

  to the Financials offering, find the General Ledger functional area, and look for the task called Manage Journal

  Sources. Open that and you get the list of all existing sources, seeded and custom. You add a new one, give it a name

  that's meaningful — something like "External Billing" or "Bank Feed" or the name of the source system — and save it.

 

  When you create a Source, there are a few important options on that setup page, and these are where the real

  functional decisions live. Let me go through the ones that actually change behavior, because the name itself is the

  least interesting part.

 

  Import Using Key

 

  There's a setting that controls whether journal import for that source references the journal entries by name or by a

  numeric ID. For most custom integrations you'll leave this in the standard configuration, but it matters when you're

  building a high-volume interface and tuning how the import behaves. It's the kind of thing you set once and forget,

  but you should know it's there.

 

  Require Journal Approval

 

  This is a genuinely useful flag. You can decide, per Source, whether journals from that source must go through the

  journal approval workflow before they can be posted. Think about what that lets you do. You might say manual journals

  require approval — because a human typed them and you want a second set of eyes — but journals flowing in

  automatically from a trusted, reconciled subledger like Payables do not require approval, because they've already been

  controlled upstream in AP. Setting approval requirements at the Source level is one of the cleanest ways to design

  your control framework. You're effectively saying "trust this origin, scrutinize that one."

 

  I've used this a lot. On one engagement the client wanted every top-side manual adjustment reviewed by the controller,

  but they didn't want the thousands of routine AR entries clogging up an approval queue. Source-level approval control

  made that trivial — turn approval on for Manual and Spreadsheet, leave it off for the subledger sources.

 

  Freeze Journals

 

  This flag controls whether users can change the journals from that source after they've been imported. When you

  "freeze" a source, journals that come in from it can't be edited or reversed through the normal journal screens —

  they're locked. You almost always freeze the subledger sources. The reason is integrity: if a journal came from

  Payables, the authoritative record lives in Payables, and the GL entry should mirror it exactly. You do not want

  someone going into GL and tweaking a Payables-sourced journal, because now your subledger and your ledger disagree and

  your reconciliation breaks. Freezing prevents that. For manual sources you typically leave it unfrozen so people can

  correct their own work.

 

  This is one of those settings where the default is sensible but you should still consciously confirm it. A frozen

  subledger source is part of what makes subledger-to-GL reconciliation trustworthy.

 

  Import Journal References

 

  This controls whether the detailed transaction references from the source system get carried into GL and stored, so

  you can drill back from a GL line to the originating transaction. For subledger sources this is how the drill-down

  from GL back to the AP invoice or AR transaction works. For custom sources, enabling reference import lets you

  preserve a link back to whatever document number or transaction ID existed in the external system, which is gold when

  someone's trying to trace an entry months later.

 

  Why the Source is the backbone of reconciliation

 

  Let me dwell on reconciliation for a moment, because this is where I think the Source earns its keep more than

  anywhere else.

 

  Every month, the finance team has to prove that the General Ledger agrees with the subledgers. The accounts payable

  trial balance has to tie to the AP liability account in GL. The accounts receivable aging has to tie to the AR control

  account. The fixed asset register has to tie to the asset cost and accumulated depreciation accounts. This is the

  foundation of a clean close, and auditors care about it deeply.

 

  How do you do that reconciliation efficiently? You isolate the GL activity by Source. To reconcile AP, you look at the

  movement in the liability account where the Source is "Payables." That movement should equal what the Payables

  subledger says it posted. If they match, you're done. If they don't, the gap is your reconciling item, and you go

  hunting.

 

  Now here's the thing that trips people up and where the Source becomes diagnostic. Sometimes the AP control account

  doesn't reconcile, and the reason is that somebody made a manual journal directly to the AP liability account in GL —

  bypassing the subledger entirely. When you filter that account by Source, you'll see most of the activity tagged

  "Payables" but then a stray line or two tagged "Manual." That manual entry is your culprit. It hit the GL but never

  touched the subledger, so the two can't agree. Oracle even provides a standard report — the Subledger to General

  Ledger Reconciliation — that leans on exactly this Source distinction to separate subledger-sourced activity from

  everything else. The whole report architecture assumes the Source tag is reliable, which is another reason you want

  your sources set up correctly and your manual postings to control accounts kept under control.

 

  I genuinely think this is the single most practical reason to care about Journal Sources. When a reconciliation

  breaks, the Source field is the first place you look, and nine times out of ten it points you straight at the problem.

 

  Source and AutoPost — automating the posting decision

 

  Another place the Source shows real muscle is AutoPost. AutoPost is the feature that automatically posts journals that

  meet criteria you define, instead of requiring someone to manually select and post them. And the criteria you define

  are built largely on — you guessed it — Source and Category.

 

  When you set up an AutoPost Criteria Set (through the Manage AutoPost Criteria Sets task), you're building a list of

  rules, and each rule line says something like "post journals where the Source is Payables and the Category is Purchase

  Invoices, for this period." You can be broad ("All" sources) or surgical (one specific source and category). Then you

  schedule the AutoPost program to run, and it sweeps through, finds everything matching your criteria, and posts it.

 

  The reason this is so handy is that it lets you treat different origins differently in terms of automation. You might

  confidently auto-post everything from the subledgers because that data has already been validated upstream. But you

  might not want to auto-post manual journals — you'd rather those go through approval and a human posting step.

  Source-based AutoPost criteria let you draw that line cleanly. You auto-post the trusted sources and hold back the

  ones that need eyes on them.

 

  In a well-run shop, the AutoPost criteria, the approval rules, and the freeze settings all line up around the same

  philosophy: subledger sources are trusted and automated, manual sources are controlled and reviewed. The Source is the

  common thread tying all three of those control mechanisms together. That's not an accident — Oracle designed it so

  the Source could be the pivot for your control design.

 

  Source in the context of Subledger Accounting

 

  If you go one level deeper, into Subledger Accounting (SLA), the relationship between subledgers and Sources gets a

  little more nuanced, and it's worth understanding because it explains some behavior people find puzzling.

 

  In Fusion, the subledgers don't just throw raw transactions at the GL. They run them through the Subledger Accounting

  engine, which applies accounting rules — account derivation, descriptions, the whole accounting method — and produces

  fully-formed accounting entries. Those entries are then transferred to GL, and that's where the Source gets stamped.

  So when you see a "Payables" sourced journal in GL, what you're really seeing is the output of the Payables SLA

  processing, summarized and handed off to the ledger.

 

  This matters for drill-down. Because the Source carries the link back through SLA to the original subledger

  transaction, you can sit in the GL, click into a Payables-sourced line, and drill all the way back to the specific

  supplier invoice that generated it. The Source is the thread you're pulling on when you do that. If you ever build a

  custom integration and you skip the reference setup, you lose that drill-back, and people will absolutely complain

  about it during the first close.

 

  It also explains why you generally don't — and shouldn't — make manual journals directly to accounts that the

  subledgers own. The subledger is the system of record for those accounts, and SLA keeps GL in sync with it. A manual

  journal to an AP control account is a journal that SLA doesn't know about and can't reconcile. The Source tag on that

  manual entry is the breadcrumb that reveals you've gone around the proper process.

 

  A few practical scenarios from the field

 

  Let me make this concrete with situations I've actually seen, because the theory only sticks when you attach it to a

  story.

 

  The mystery balance. A controller comes to you because a particular expense account has a balance that nobody can

  explain. You pull up the account activity, you group it by Source, and immediately you see that 95% of it is

  "Payables" — fine, those are invoices — but there's a chunk tagged "Spreadsheet" from an upload three weeks ago. Now

  you've narrowed the investigation from "the entire account" to "one spreadsheet upload," and you can find who did it

  and why. The Source turned a needle-in-a-haystack problem into a five-minute lookup.

 

  The integration that polluted the manual source. A client built an interface from their external billing system but

  didn't create a dedicated Source — they just shoved everything in under a generic value. Six months later, their

  "Manual" journal volume looked enormous and their internal audit team flagged it because manual journals are a control

  risk. We had to retrofit a proper "External Billing" Source so that the genuine manual entries (the ones auditors

  actually care about) could be separated from the automated interface traffic. The lesson: always give an external

  interface its own Source. It costs nothing to set up and it saves you from this exact mess.

 

  The close that wouldn't tie. During a month-end, the AP reconciliation was off by a few thousand dollars. Filtering

  the liability account by Source showed the subledger activity tied perfectly, but there was a single "Manual" line

  someone had posted to fix a different problem and accidentally hit the AP control account. Because the Source flagged

  it as manual rather than Payables, we knew instantly it was an out-of-process entry, reversed it, and the

  reconciliation cleared. Without the Source, we'd have been comparing totals and guessing.

 

  Designing approvals for a new client. When standing up GL for a new client, one of the early conversations is "what

  needs approval?" The clean answer almost always routes through Source. Subledger sources are pre-controlled, so no GL

  approval needed. Manual and Spreadsheet sources are where humans introduce risk, so those get approval workflow. We

  configure that on the Manage Journal Sources page with the Require Journal Approval flag, and the whole control story

  is suddenly simple to explain to the auditors. They love it because it's a clear, source-based policy rather than a

  tangle of one-off rules.

 

  Common misunderstandings worth clearing up

 

  A few things consistently confuse people, so let me address them head-on.

 

  "Source and Category are the same thing." They're not. Source is origin, Category is type. You can have many

  categories within one source. Payables alone might generate Purchase Invoices, Payments, Prepayments, and more — same

  Source, different Categories. Keep them distinct.

 

  "Uploaded journals are manual." Nope. If they came through the import spreadsheet, they're "Spreadsheet" sourced, not

  "Manual." This trips up nearly everyone at first. It's actually a helpful distinction once you embrace it, because

  bulk uploads and hand-keyed entries carry different risk profiles and now you can tell them apart.

 

  "I can rename a seeded source." Don't try to repurpose the seeded sources. They're tied to subledger behavior. If you

  need a new origin, create a new Source. Leave Payables meaning Payables.

 

  "The Source controls the accounting." It doesn't drive what accounts get hit — that's account derivation and SLA's

  job. The Source is metadata about origin. It influences process controls (approval, freeze, autopost, reconciliation)

  but not the debits and credits themselves. Don't expect changing a Source to change where money lands.

 

  "Custom sources need custom code." For the most part, no. You define them through the Manage Journal Sources setup

  task, and you reference them in your Journal Import data. The configuration is functional, not technical. You only get

  into technical territory if you're building the integration that feeds the import, and even then the Source itself is

  just a value you populate.

 

  How the Source flows through the journal lifecycle

 

  It helps to picture the full lifecycle and see where the Source attaches and what it does at each stage.

 

  At creation, the Source is stamped. If it's a subledger transaction, the subledger and SLA assign the correct seeded

  Source automatically. If it's manual, the system marks it Manual. If it's an import, the Source comes from the data

  you load — which is why your interface has to specify it. If it's a spreadsheet upload, it's marked Spreadsheet. The

  Source is set at birth and it doesn't change.

 

  At approval, the Source can determine whether the journal even needs to go through workflow, based on your Require

  Journal Approval setting. So the Source is already steering the journal's path before it's posted.

 

  At posting, AutoPost criteria can match on the Source to decide whether the journal posts automatically. The Source

  is, again, the routing key.

 

  After posting, during inquiry and reporting, the Source is one of your primary filter and grouping attributes. Account

  analysis, the Journals report, OTBI, Smart View — Source is everywhere as a slicer.

 

  During reconciliation, the Source separates subledger activity from manual activity, which is the entire basis of

  subledger-to-GL tie-outs.

 

  And throughout, the freeze setting tied to the Source governs whether the journal can be touched after the fact,

  protecting integrity for the sources where it matters.

 

  So the Source isn't a one-time tag that gets forgotten. It actively participates at almost every stage — approval,

  posting, reporting, reconciliation, and protection. That's why I keep calling it a backbone. It really does run the

  length of the whole process.

 

  Setting it up well — a short checklist from experience

 

  If you're implementing or cleaning up a Fusion GL and you want your Journal Sources working for you instead of against

  you, here's roughly how I'd approach it.

 

  First, leave the seeded subledger sources alone and make sure they're frozen and excluded from journal approval,

  because the controls belong upstream in the subledgers. Confirm the freeze and approval settings rather than assuming

  them.

 

  Second, for every external system feeding the GL, create a dedicated, clearly-named Source. Don't let external data

  hide inside Manual or Spreadsheet. Name it after the system or the business meaning so that two years from now someone

  who's never met you can look at a journal and know exactly where it came from.

 

  Third, decide your approval policy along Source lines. Manual and Spreadsheet generally get approval; trusted

  automated sources generally don't. Configure that on the Manage Journal Sources page and document the rationale for

  the auditors.

 

  Fourth, build your AutoPost criteria around Source and Category so that trusted origins post automatically and risky

  ones wait for human review. This keeps the close fast without sacrificing control.

 

  Fifth, make sure reference import is enabled where you need drill-back, especially for custom integrations. The first

  time someone can't trace an entry to its source document, it becomes a fire drill. Set it up correctly up front.

 

  Finally, train the team to use the Source field when they investigate anything. Mystery balance? Group by Source.

  Reconciliation off? Filter by Source. It's the fastest diagnostic in the GL and it's sitting right there, but only the

  people who've been shown its value actually reach for it.

 

  Wrapping up

 

  The Journal Source looks like a humble little label, and in a sense it is — it's just a tag that says where a journal

  came from. But that one piece of information threads through almost everything that matters in the General Ledger.

  It's how you reconcile subledgers to the ledger. It's how you decide what needs approval and what can post

  automatically. It's how you protect subledger-sourced entries from being tampered with. It's how you trace a balance

  back to its origin during the close, and it's how you separate the routine, trusted, automated traffic from the manual

  entries that carry real control risk.

 

  For a functional consultant, getting comfortable with Journal Sources pays off out of all proportion to how simple the

  concept is. When a client is confused about where a number came from, the Source answers it. When a reconciliation

  breaks, the Source points at the cause. When you're designing controls, the Source is the natural axis to design

  along. And when you're bringing external data into the ledger, defining the right Source is the difference between a

  clean, traceable feed and a murky pile of entries nobody can explain later.

 

  So treat the Source with a bit more respect than its size suggests. Set it up deliberately, use it consistently, and

  lean on it whenever something in the ledger needs explaining. It's one of those quiet features that, once you really

  get it, makes the whole General Ledger feel a lot more transparent and a lot easier to manage.