SAP Reports

• Financial statements: balance sheet and profit-and-loss.
• G/L, AP, AR, asset account balances and line items.
• Open item and aging reports (receivables/payables).
• Tax reports for returns.

Two more worth knowing by name because finance asks for them constantly. The trial balance lists every account with its opening balance, movements and closing balance, and it is the report used to check a period before closing. And ageing for receivables and payables groups open items by how overdue they are, which is the number collections and treasury actually work from.

Financial statements are the output. The reports finance people live in are the line item lists, and knowing them by transaction is most of being useful.

FAGLL03 lists general ledger line items, with open and cleared status, for any account and period. This is where an investigation starts when a balance looks wrong.

FBL1N and FBL5N do the same for vendors and customers, and they are the sub-ledger equivalents: what is owed, to whom, and how old.

FAGLB03 shows balances rather than items, which is the view for comparing periods.

F.01 produces the financial statement itself, structured by the financial statement version.

The pattern worth learning is drilling: start at the balance, open the line items behind it, open the document behind a line, and open whatever created that document. Four steps from a number in a report to the goods receipt or billing document that caused it, and being able to walk that quickly is the skill finance teams value in a consultant.

The universal journal (ACDOCA) provides one real-time source for financial and management reporting, so many reports run on live data without separate aggregation. Fiori analytical apps and SAP Analytics Cloud provide modern, interactive reporting, while classic reports and drill-down remain available.

What that changes in practice: reporting reads one table, so a report can slice by cost centre, profit centre, segment and functional area without joining anything, and management and statutory views come from the same lines rather than from two reconciled sets. It is also why many aggregate tables and the reports built on them disappeared, and why a custom report reading the old line item tables needs rewriting during a conversion.

A balance sheet is not stored anywhere. It is produced by arranging general ledger accounts into a hierarchy, and that hierarchy is the financial statement version.

It defines the structure: assets, liabilities, equity, income, expense, with as many levels beneath as the reporting needs. Each node has accounts assigned, and the report sums them.

Several versions can exist, which is how a company produces a statement under local rules and another under group reporting from the same postings.

Two failure modes are common and both are visible in the output. Unassigned accounts appear in a catch-all node, so a new account created without being added to the version shows up outside the structure and the statement does not balance where people expect. And a version nobody maintains drifts as the chart of accounts grows, until the statement needs manual adjustment every period, which defeats the point.

The maintenance discipline is small: adding an account to the financial statement version is part of creating it, not a separate cleanup exercise. See FI configuration.

Good FI reporting depends on clean configuration (chart of accounts, financial statement version) and consistent postings. The financial statement version defines the structure of the balance sheet and P&L; getting it right is what makes statements meaningful.

The other half of reporting well is knowing when not to build a report. A great deal of what gets requested exists already in the standard reports with a different layout or variant, and saving a variant is minutes where a custom report is days and something to maintain forever. The question to ask before building anything is which standard report is closest and why it does not do.

Half an hour, and it is the skill that makes you useful to a finance team.

1. Run F.01 and pick a line that looks unexpected.
2. Note which accounts feed that node in the financial statement version.
3. Run FAGLB03 for one of those accounts and compare periods to find when it moved.
4. Run FAGLL03 for that account and period, and sort by amount. The outlier is usually obvious.
5. Open the document. Read the document type: manual journal, invoice verification, billing.
6. Follow the reference to the originating document, and you have the transaction that caused it.

Six steps, and the answer is almost never in finance. It is in whichever process created the document.

An account flagged for open item management behaves unlike an ordinary one, and understanding why explains a whole category of finance reporting.

On an ordinary account, postings accumulate and the balance is the sum. On an open item managed account, each posting is either open or cleared, and the useful figure is not the balance but which items remain open.

Vendor and customer reconciliation accounts work this way, and so do clearing accounts, notably the goods receipt and invoice receipt clearing account. That is the mechanism behind the classic finance question of what is sitting on the clearing account: it should net to zero as receipts and invoices match, and an aged open balance means they have not.

Clearing can be manual, somebody matching items, or automatic, run by a program matching on rules such as reference or amount. Automatic clearing with well-chosen criteria is what keeps the account readable, and criteria that are too loose match things that should not have been.

The practical consequence for reporting: on these accounts run the open item list rather than the balance, because the balance is a net figure that can be small while thousands of unmatched items sit underneath it.

• Standard report with a variant, or a custom one. Variants are minutes and are maintained by the business. Custom reports are days and are maintained by you, forever.
• Who owns the financial statement version. Adding new accounts to it has to be part of creating them, or the statement drifts.
• Where analytical reporting lives. Operational reporting on the journal, and cross-system or heavily modelled reporting in a warehouse, with the division decided rather than emerging.
• What is reported before the close. Numbers read mid-period are a snapshot, and publishing them without saying so is how two versions of the truth start circulating.

• Poor financial statement version, meaningless structure.
• Reporting on inconsistent postings.
• Ignoring S/4HANA real-time analytics.

• Building a custom report before checking the standard ones. Most requests are a layout variant.
• New accounts not added to the financial statement version. They appear outside the structure and nobody notices until the statement is reviewed.
• Reporting on a period before it is closed. See FI integration, FI examples and SD reports for related reporting.

• Reporting on an open item account by its balance. The net figure can be small while thousands of unmatched items sit underneath it.

Running a report is straightforward, and configuring the financial statement version and the account structure behind it so the statements are meaningful is the part you do in the course.

The skill to practise is drilling: balance, line items, document, originating document. Four steps, and the cause of nearly every questioned figure is at the end of them and not in finance.