Build and review finance metrics

In Schemas → Finance Metrics, check the active catalog before creating a metric. Reuse an existing definition when it already measures what you need. A new definition should describe a distinct business measure.

• General Ledger accounts: total selected accounts or account classifications. Choose activity during a period or a supported balance at period end.
• Unit Register: use an active Atomic Unit Metric. A balance metric can report its closing balance or period movements; selected movement types retain signed corrections.
• Over a time window: sum an existing General Ledger activity metric or average an existing Trial Balance metric’s month-end balances over a fixed window. This path does not support lifetime windows.
• Formula: add or subtract compatible existing metrics, with parentheses where needed. Multiplication, division, and numeric constants are not formula inputs. Choose Ratio for division.
• Ratio: divide compatible metrics using an explicit calculation pattern and result unit.

PipeLedger-managed measures have fixed calculation bindings. Reviewing one does not make its underlying warehouse calculation editable.

The source and measure determine which accounts, classifications, and existing metrics can be selected. Ordinary formulas and ratios require compatible metrics from the same source and time behavior. Temporal ratios use their operands’ supported activity and balance sources.

Account selections use governed values. Pending classifications can be selected before publication, but begin contributing only after a successful transformation and publication. The editor marks unavailable selections and blocks unsupported edits.

Saved scope restrictions remain part of the definition. Definitions with multiple inclusion, exclusion, or scope rules that the editor cannot preserve are blocked from saving there; use the supported catalog authoring contract for those definitions.

When you choose the Formula metric type, the builder asks for Formula purpose. Both options use the same addition and subtraction controls. Choose according to what the metric means, rather than how simple or complex its formula is.

• Standard formula: choose this for an ordinary combination of existing metrics, such as adding two expense metrics to report their combined cost. You are defining a total or difference without presenting it as an adjusted version of another figure. “Standard” is the editor’s label; it does not certify the result as GAAP-compliant or make it a financial statement line.
• Adjusted or non-GAAP: choose this when you deliberately modify a reference figure for a supplementary reporting purpose, such as adding a selected expense back to operating profit to present adjusted operating profit. Name the adjustment and explain what you include or exclude. GAAP means generally accepted accounting principles; this option labels the metric as a supplementary, adjusted measure.

For example, a fictional company could use Standard formula for “Travel expense + Accommodation expense” to show combined trip costs. If it instead defines “Operating profit + Selected restructuring expense” as adjusted operating profit, it would choose Adjusted or non-GAAP. The expense must already exist as a compatible governed metric, with the intended scope and sign.

Choosing Adjusted does not identify exceptional items, exclude transactions, or add anything back automatically. You must build the actual formula from the appropriate metrics. Changing this selection alone leaves the formula and its numerical calculation unchanged.

The selection changes how the definition is organized: Standard uses the Custom family and Organization metrics collection. Adjusted uses the Adjusted family and Extended metrics collection, and adds the Non-GAAP tag. Switching back to Standard removes the Non-GAAP and Adjusted EBITDA tags if present. Other selected tags remain. Both choices use the same draft and activation process.

Before saving an adjusted formula, describe the reference figure, each adjustment, and the reason for it in Purpose. An active metric’s revision keeps its existing family, so Formula purpose is fixed when revising it. This choice applies to the Formula path; it is not a separate calculation mode for ratios or account-based metrics.

A metric can include one account or a selected set of accounts. For example, you can track activity in a particular construction-in-progress account without including every account in its category.

1. Choose General Ledger accounts as the metric type.
2. In the builder, set Build from to Account ID.
3. Search the available accounts and select the entries you need, checking their names and IDs. The selection uses the account ID; matching display names do not make accounts interchangeable.
4. Choose period activity or a supported closing balance, then describe the selected accounts in the metric’s purpose.

Choose a classification, such as Catalog Category or Project economic role, when the metric should follow that governed grouping instead. An explicit account selection includes the chosen accounts; it does not automatically include other accounts later assigned to the same category.

For a supported period-activity metric, Activity direction selects which postings contribute. All activity (net) keeps both sides. Choose Debit only or Credit only for ledger activity, or Inflows only or Outflows only for eligible actual cash movements. Account selection and activity direction work together: only the selected side of the selected accounts contributes.

For a fictional asset account with $900 of debit postings and $200 of credit postings, debit-positive net activity is $700. Debit only produces $900. Credit only selects the $200 of credit postings, with the displayed sign determined separately. A debit selection does not mean cash spending, and a credit selection does not necessarily mean revenue or refunds.

Presentation sign sets whether debit or credit is positive; it does not select postings. A source-owned final sign is shown as fixed. Direction selection belongs to an atomic activity metric, not a closing balance or the ratio itself. To use selected postings in a formula or ratio, first define the activity metric and then choose it as a compatible input. Unit Register activity uses its separate movement-type selection and retains signed corrections.

For tool authors, the definition field is activity_direction: use debit, credit, inflow, or outflow where supported, or omit it for all activity. General Ledger Lines and eligible cash movement sources apply this selection through line_direction. Trial Balance and supported project-position activity use their debit or credit amount columns instead. Cash balances and indirect cash-flow adjustments do not have a cash-movement direction. These selections preserve the source’s access restrictions.

The calculation choice determines what the numerator and denominator mean. The same two metric names can produce different measures when their timing differs. A temporal ratio defines that time relationship: it can compare activity over a window with a balance at one or more dates. “Temporal” does not mean the metric is temporary.

• Activity ratio: two totals from the same reporting period.
• Point-in-time ratio: two balances at the same reporting date.
• Accumulated activity ratio: two activity totals accumulated over the same fixed or lifetime window.
• Activity over balance: activity divided by the ending balance, average opening and closing balances, average month-end balances, or peak positive combined month-end balance, according to the selected pattern.
• Ending balance over activity: an ending balance divided by accumulated activity.

Choose Ratio, select the calculation pattern, then choose compatible numerator and denominator metrics. For temporal patterns, activity inputs use General Ledger Lines; balance inputs use Trial Balance or a supported project financial position source. Set the time window, annualization, and result unit explicitly. The definition keeps these choices; the reporting month-end determines the actual dates when the metric runs.

Available windows are a single month, fiscal quarter, fiscal year, trailing 3, 6, 12, or 24 months, and lifetime. The same window applies to both inputs of an accumulated activity ratio.

Lifetime activity means all available recorded history through the reporting month-end. It is not a promise that the source contains every transaction since the business began.

Fixed windows require complete history. Monthly averages require every month-end balance in the window, combining balances within the reporting scope before averaging. Missing required history makes a result unavailable; PipeLedger does not silently shorten the window. Fiscal quarter and year windows must end on the organization’s exact fiscal boundary, and reporting anchors must be elapsed month-ends.

An activity-over-average-balance ratio divides the total activity in the window by an average balance. There are two distinct methods; choose the one your reporting definition requires.

• Average opening and closing balances: add the opening balance immediately before the window and the closing balance at its end, then divide by two. For January through March, these are December 31 and March 31. Intermediate month-ends do not enter this average. The calculation is activity_over_average_balance.
• Average month-end balances: average every month-end balance inside the window. For January through March, these are January 31, February’s final day, and March 31. Each month-end has equal weight; this is not a daily average. The calculation is activity_over_monthly_average_balance.

For the monthly method, PipeLedger combines the selected accounts and entities within the reporting scope for each month, then averages those monthly totals. It does not average separately calculated entity ratios. Every required month-end must be present; a zero or negative monthly average makes the return unavailable.

To report the monthly average as a currency amount alongside the ratio, use Over a time window → Average month-end balances with a compatible Trial Balance metric and the same fixed window. This supporting amount uses month_end_average; it does not support a lifetime window.

Peak balance is the highest positive combined month-end balance in the selected fixed or lifetime window. An activity-over-peak-balance ratio divides the window’s activity by that amount. This can express a project’s return against its highest recorded month-end capital balance, provided the chosen metrics represent that income and capital.

PipeLedger combines the selected account and entity balances within the reporting scope for each month before finding the peak. It does not add up individual accounts’ or entities’ peaks from different months. Amounts added and cleared within a month can be missed by month-end snapshots, so this is not a daily or intraday high-water mark.

Every required month-end must be covered. If the peak is zero or negative, the return is unavailable. Peak-balance ratios do not allow annualization. For tool authors, the calculation identifier is activity_over_peak_balance in temporal_ratio.calculation; “peak balance” is the balance basis, not a standalone authoring kind named peak_balance.

In this fictional January–March example, activity totals $60,000. The opening balance on December 31 is $100,000, and the month-end balances are $200,000 in January, $300,000 in February, and $400,000 in March. Each result below uses Percentage with no annualization.

• Opening/closing average: ($100,000 + $400,000) ÷ 2 = $250,000. The return is $60,000 ÷ $250,000 = 24%.
• Monthly average: ($200,000 + $300,000 + $400,000) ÷ 3 = $300,000. The return is $60,000 ÷ $300,000 = 20%.
• Peak balance: the highest month-end is $400,000. The return is $60,000 ÷ $400,000 = 15%.

These results answer different questions. Record the balance method and window in the purpose so readers know which comparison they are seeing.

Annualization is available for eligible fixed-window activity-over-balance returns. Linear annualization multiplies the quotient by 12 divided by the number of months. It is not a compounded investment return. Lifetime, peak-balance, activity-over-activity, and balance-over-activity ratios are not annualized.

Choose Percentage or Multiple explicitly. The stored result remains the raw quotient: 0.40 displays as 40% for a percentage, while 1.50 displays as 1.50x for a multiple. Percentage-point differences and relative percentage changes are different comparisons.

Calculation details in the editor expose the exact expression for inspection. This is a description of the governed calculation, not an arbitrary SQL editor.

Use a short business name and a purpose that explains what is included and why the metric is useful. The stable metric ID identifies the definition across tools and revisions; it cannot be changed when revising an existing metric.

Metric family follows the authoring path. Organization-specific metrics normally use Custom; a formula explicitly designated as adjusted or non-GAAP uses Adjusted. Revisions retain their family. Catalog section and tags help people find a metric. They do not add it to a fixed financial statement.

Metrics Report presents an ordered selection of governed metrics. It is separate from the Income Statement, Balance Sheet, and Cash Flow Statement. See the report tool guide for report behavior and limits.

Saving creates or updates a private draft. Editing an active metric creates a revision draft; the active definition keeps serving until the revision is approved and activated. Review changed settings and dependent metrics before activation. Full settings and the active definition hash remain available for inspection.

Project Overview and Reporting Entity Metrics are independent BI destinations: select either or both when eligible and configured. Project Overview follows the organization’s industry setting. Source-wide entity and history settings live in BI Sharing – Metrics Settings.

Draft delivery selections apply on activation. BI publication is a separate process, so an active definition and the revision actually delivered can temporarily differ. Check delivery status before expecting a dashboard to use a new revision.

For precise definitions, discovery, and authorized authoring through MCP, REST, or CLI, see catalog discovery and catalog authoring. Those contracts retain exact identifiers, calculation rules, and revision evidence.