The report that ran in forty seconds and then eleven minutes
Reporting inside Oracle Fusion Cloud ERP should answer questions about work that is still open. The moment a question needs a second year of closed history, or a join to something Fusion has never held, it belongs in an extract and a warehouse. Building it in OTBI anyway is cheap on the day and expensive at the third year end.
I built an accrual summary for a manufacturing client's month end close in BI Publisher, over a data model joining journal lines to Payables invoice distributions with a handful of segment filters. In the test pod it came back in forty one seconds against nine months of converted data. Two and a half years after go live the same report took eleven minutes, and the close checklist carried a step telling the accountant to submit it before six in the morning.
Nothing had broken. The report scanned every posted line in scope, and the scope grew every month, from around six hundred thousand journal lines at go live to just over four million. A report whose row count grows with the calendar rather than with open work has already crossed the line, whether or not anybody has noticed.
OTBI earns its keep on open work
The questions Fusion answers well share a shape. Which invoices have sat in approval for more than five days. Which requisitions still have no buyer. Which subledger journals have not transferred to General Ledger for the period being closed. Each one reads live data, applies the user's own data access set without anyone writing security code, and drills from the total down to the transaction somebody has to go fix. A business unit manager sees only their own rows because Fusion role security did the filtering.
Teams over-build in this layer because of the budget line. An analyst with the BI Author role ships something on a Tuesday afternoon with no procurement and no conversation with the platform owner. A warehouse proposal starts with a cost and a steering committee. The easy path keeps winning until it stops working, and it stops working during close.
The view that quietly changed its answer
The other failure does not announce itself. A client ran a BI Publisher report of unposted Payables accruals built on custom SQL against a transactional view instead of a supported subject area, because the subject area did not expose one attribute the controller wanted. The SQL filtered on business unit and period. It did not filter on ledger, since at the time there was only one.
Fifteen months later an acquired legal entity went live with its own primary ledger under the same business unit. The view started returning rows the report had never seen, and the accrual total moved by roughly one point nine million across two periods before a reconciliation caught it. No error, no warning. The report answered a slightly different question than the one it was signed off against.
Transactional structures inside Fusion are internal surfaces, and a configuration change is a version bump nobody sends you a note about. The habit that keeps small integration contracts honest works here too. Write down what the report assumes, and put a check beside the number that fails loudly when the assumption stops holding.
Sort the request before anyone opens the editor
Four questions settle most requests in about ten minutes, asked out loud when the request arrives. The first is whether the answer changes if you run the report an hour later. Live and moving means operational, and it stays in Fusion. The second is how many closed periods the answer spans. One is fine. Three fiscal years of them is an extract.
The third is whether the answer joins anything Fusion does not hold. Shipment scans from a warehouse system, or headcount from an HCM tenant nobody merged. No version of that request ends well inside OTBI, and the workaround people reach for, uploading a spreadsheet into an analysis, produces a number with no owner and no lineage.
The fourth is what the reader does with the output. A list somebody works through row by row belongs where the rows live, because the reader will click into a transaction and change it. A number somebody reasons about over time belongs in the warehouse, because nobody drills from a trend into a journal line. Settling this before the build is the same discipline as making analytics questions a product requirement.
What the tipping point actually looks like
The tipping point shows up in behaviour before it shows up in a runtime. Somebody schedules the report instead of opening it. Somebody asks for the same period last year beside the current figure. Somebody exports the output and joins it to another sheet by hand. That last one is the loudest signal in the building, because the spreadsheet is now doing the warehouse's job with one maintainer who takes August off.
If you want a runtime threshold, mine is two minutes. An operational report that runs longer is telling you its question stopped being operational, and it will not get faster on its own. General Ledger is the exception, because the balances cube answers plenty of period over period questions without touching journal detail, so the line sits further out for GL than for Payables detail.
The extract mechanics are well trodden. BI Cloud Connector publishes view objects incrementally on last update date into object storage, and the warehouse picks them up on whatever cadence finance agreed to. Fusion Data Intelligence gets you there faster when the prebuilt model fits. The decision that matters happens in the request meeting rather than in the tool comparison.
The extract side has its own bill
Moving a report out of Fusion costs something, and pretending otherwise is how warehouse programmes lose credibility in month four. Data access sets and ledger assignments that OTBI applies for you do not travel with a flat extract, so somebody has to decide who sees which ledger in the new place. That somebody is usually the person who least wants the job.
Reconciliation is the second bill. Once a trend lives outside Fusion, somebody compares it to the trial balance and finds a difference, and the difference will be real for boring reasons. Late postings arriving after the extract window, or a period reopened for an adjustment. Put the extract timestamp and a tie out status beside the figure, the same way you would on a dashboard that becomes a decision surface, and keep the ledger id and document number on every extracted row so anyone can trace a figure back through durable business keys.
The split matches the one that applies when a lake sits next to a ledger. The controlled number lives where it was posted, the broad history lives in the copy, and any page mixing the two says which is which. Fusion makes that mistake easy, because the reporting tool is already logged in and already holds the data.
The line to add to your report intake form
Ask every requester how many years of data the answer needs, and ask what the report looks like when the company has three more years of it. Most people answer honestly, because nobody wants to own the report that takes eleven minutes on close day.
Requests that come back with one open period and no outside joins get built in OTBI that week. Everything else gets a line in the warehouse backlog and a real date. Pull the last five things your team shipped in OTBI and check how many would pass that question today. If it is fewer than three, the architecture conversation is already overdue.
