Financial Statements

The Financial Statements workspace is the setup engine for PinkApple’s structured statutory and management statements.

Navigation: Administration -> Reporting -> Financial Statements

What Lives In This Screen

The screen is organized into these tabs:

• Templates
• Line Items
• Account Mappings
• Column Definitions
• Column Sets
• Notes
• Manual Amounts

These are not independent tools. They are different layers of one statement engine.

How The Statement Engine Works

At a high level, a financial statement is built like this:

Template
  -> Lines
     -> Account Mappings
     -> Column Definitions / Column Sets
     -> Notes / Manual Amounts
  -> Report Definition
  -> Runtime Generation

That means a statement is only truly complete when:

• the FS configuration exists
• the report definition links to that configuration
• the statement runs successfully in Reporting -> Reports

Recommended Build Order

Create financial statements in this order:

1. Templates
2. Line Items
3. Account Mappings
4. Column Definitions
5. Column Sets
6. Notes
7. Manual Amounts
8. Report Definition linkage
9. Runtime validation

Templates

Templates define the statement family and its long-lived identity.

Typical templates are:

• Balance Sheet
• Income Statement
• Cash Flow Statement
• Statement of Changes in Equity

Use templates to define:

• statement code
• statement name
• statement type
• business purpose

Templates should be stable and business-readable. Do not design them around temporary period-end needs.

Line Items

Line items define the body of the statement in display order.

Common line uses:

• section headers
• detail rows
• subtotal rows
• total rows
• derived or formula rows

Line quality matters because it determines:

• how readable the statement is
• where values accumulate
• how mapping and derivation behave
• what users can drill into and explain

Build lines in the exact order the finance team expects to read the statement.

Account Mappings

Account mappings connect the chart of accounts to statement lines.

This is the most important reconciliation layer in financial statement setup. If mappings are wrong, the final statement is wrong even when every other setup screen looks correct.

When mapping, validate:

• account category
• natural balance behavior
• whether the line should represent position or movement
• whether multiple accounts should roll into the line
• whether mappings should behave consistently across business units

Column Definitions

Column definitions are reusable report columns.

Common examples:

• current period
• prior period
• year to date
• budget
• variance
• variance percentage

Use column definitions when a statement needs multiple analytical views without duplicating the line structure.

Column Sets

Column sets package column definitions into runtime layouts.

Good examples:

• current period only
• current vs prior
• current vs budget
• current, prior, variance

Column sets let one template serve different reporting audiences without cloning the whole statement.

Notes

Use Notes for narrative or disclosure content that belongs to the statement pack.

Typical note use cases:

• accounting policy notes
• explanatory disclosures
• structured supporting commentary

Notes should support the statement, not compensate for bad line or mapping design.

Manual Amounts

Use Manual Amounts for controlled values that are intentionally not derived purely from the mapped GL data.

Appropriate uses include:

• approved management adjustments
• disclosure values maintained outside direct GL aggregation
• statement elements that require controlled manual contribution

Manual amounts should be used sparingly and governed carefully, especially around period end.

Linking Financial Statements To Runtime

Financial statements become runnable through the Report Catalog.

To expose one to users:

1. Create the template and complete its setup.
2. Create a report definition with:
   • report_type = FINANCIAL_STATEMENT
   • the approved statement procedure
   • the linked FS template
   • the relevant column set, if one is needed
3. Activate the definition.
4. Validate the statement in Reporting -> Reports -> Run Reports.

Runtime Behavior

When a user runs a financial statement, the parameter area may prompt for:

• from date
• to date
• currency
• business units
• template
• column set

The report viewer then renders the statement structure rather than a generic flat table, provided the definition and output contract are correct.

Financial Statement Validation Checklist

Before releasing a financial statement, confirm:

• every required line exists and is correctly ordered
• mappings reconcile to intended GL balances
• derived lines calculate correctly
• comparative columns behave correctly
• notes are attached where needed
• manual amounts are reviewed and understood
• the report definition points to the correct template
• the statement renders correctly in runtime
• exports are complete and readable

Related Pages

• Implementation Model
• Administration & Setup
• Creating Reports In The UI
• Report Catalog
• Operations & Usage