One arrow from S/4HANA to the lake hides the real question
The architecture slide had one arrow. S/4HANA on the left, a lakehouse in the middle, Power BI on the right, and every finance report in the company fed from the same gold layer, from the exploratory margin analysis to the pack the board signs. I asked which of those pages the auditors would see. The finance systems lead said the trial balance out of the Universal Journal, as always. So the pack and the trial balance were about to be two different numbers, and the slide had no way to say so.
A lake and a ledger do different jobs. The ledger holds the controlled transaction state, the lake holds a wide and forgiving copy of history, and the design has to say which questions belong to each. A page that mixes the two owes its reader the extract time, the exclusions, and whether the copy ties back.
The ledger is slow on purpose
Everything that makes the Universal Journal in S/4HANA worth signing also makes it a poor place to explore. Each line carries a document number, a posting date, a fiscal period, and the user who posted it. Periods close and stay closed. A correction is a new document that reverses the old one. An auditor can start from a figure on the balance sheet and trace it back to the line, the approver, and the day.
An analyst who wants five years of sales order lines joined to CRM opportunities, shipment scans, and web sessions does not want any of that. They want history the ERP has archived, joins across systems the ERP has never heard of, and room to be wrong for a fortnight while the question sharpens. Point that workload at the journal and the Basis team will be in your inbox by the second week of a quarter close.
The lake, and a Power BI model over it, gives the analyst all of that room. What it cannot give is the signed number, because its copy of the ledger was taken at a time, under exclusions, after whatever the pipeline did to the rows on the way in.
Put every finance question in a column
The most useful page I have added to a data architecture document is a two column table. Left, the question. Right, the system that answers it. Trial balance by company code and period goes to the ledger, because that is what gets signed. Margin by product family over five years goes to the lake, because nobody sized the ERP to be scanned that far back. Open item ageing goes to the ledger when a collector is about to phone a customer and to the lake when a manager wants the eighteen month trend.
Filling the table forces the arguments to happen early. The FP&A lead wants the close pack built in Power BI because the visuals are better and the lakehouse already has the data. The finance systems lead wants every dashboard reading S/4HANA directly through CDS views because she does not trust a pipeline she cannot see. Once the rows are written down they usually agree on more than they expected. The argument about what revenue even means on those pages is one I have covered in who gets to define revenue, and the answer holds here. Finance owns the definition and the data team owns the copy.
If the table comes out with every row pointing at the lake, the design is quietly building a second ledger. If every row points at the ERP, the lake was never needed and the licence money is better spent elsewhere. Either way, write the table before anyone argues about which analytics questions the project must answer.
Definitions cross the line, corrections do not
Master data travels from the ledger to the lake unchanged. The chart of accounts, the company codes, the profit centre and cost centre hierarchies, the fiscal year variant, and the currency translation rules already have an owner in S/4HANA. Extract them as they are and build the Power BI model on them. A lake that carries its own account hierarchy guarantees that the argument about the mapping has to finish before the argument about the numbers can start.
The worst version I have reviewed was an Excel sheet on one analyst's desktop that mapped GL accounts to reporting lines. Finance restructured the hierarchy in the ERP in March. The sheet caught up in June. For one quarter the dashboard and the trial balance disagreed on operating expenses and nobody could say why, because the difference lived in a file the pipeline never saw.
Corrections go the other way only. I have seen a scheduled notebook that adjusted intercompany balances in a lake table, and that table fed the page the group controller opened at close. No document number, no period lock, no approver, no trace. If a figure is wrong, the fix is a posting in S/4HANA that the next extract picks up. Keep the document number, company code, and fiscal year on every lake row exactly as posted, because those are the durable keys that let anyone trace a number on a page back to the line that made it.
Show the extract time and the tie-out beside the number
The disagreement that taught me this was a back dated journal. The lake loaded incrementally on entry date, and a controller posted a manual journal into a period the lake had already marked closed, with a posting date inside that period and an entry date three days later. The load picked up the document and filed it under the wrong month, so the lake's closed period stayed tied at the total level while two lines sat in the wrong bucket, and the page rounded the whole thing to look precise.
Nothing in that story was a defect. What was missing was any way for the reader of the page to know. So any page that shows a ledger derived figure from the lake should carry three things next to it: when the copy was taken, what was excluded, and whether it ties. I build that as a reconciliation table in the lake. For each company code and period it holds the lake total, the ledger total as at the extract timestamp, the difference, and a status the finance systems lead agreed to. Tied, open, or over tolerance.
The Power BI page then shows the status beside the figure it affects. That is a few days of engineering and it changes the meeting, because the review reads the status column and gets on with the design. The case that a dashboard should be built around a decision already puts freshness and known gaps beside the measure. A tie-out status is that case applied to a number someone will be asked to sign.
When the slide says single source of truth
The slide always comes. Someone presents the lakehouse as the single source of truth for finance, and the finance systems lead goes quiet in the way that means the close is staying exactly where it is. My question at that point is which number goes to the auditor. That one lives in S/4HANA under the controls that make it worth signing. The lake copy is analysis, allowed to be broader and faster than the ledger, and allowed to be a little wrong provided the page says so. Once that is said out loud the slide usually gets one more word on it, and the word is analytical.
Before your next review, take last quarter's close pack and, beside every figure, write which system it came from and when the copy was taken. The figures you cannot annotate are the rows nobody has claimed in the table, and they are where the next long argument is waiting.
