Update Finance Concepts
@@ -9,11 +9,11 @@ This page explains the FP&A domain concepts implemented in the engine. It's usef
|
||||
A variance is the difference between a budgeted amount and an actual amount for a given GL account, department, and fiscal period.
|
||||
|
||||
```
|
||||
variance_abs = actual − budget
|
||||
variance_pct = (actual − budget) / budget × 100
|
||||
variance_abs = actual - budget
|
||||
variance_pct = (actual - budget) / budget x 100
|
||||
```
|
||||
|
||||
Whether a variance is good or bad depends on the **account type** — see Favourability below.
|
||||
Whether a variance is good or bad depends on the **account type** - see Favourability below.
|
||||
|
||||
---
|
||||
|
||||
@@ -29,7 +29,7 @@ A cost going over budget is bad. Revenue coming in above budget is good. The eng
|
||||
| CAPEX | `false` | actual < budget (capital spend under plan) |
|
||||
| Headcount | `false` | actual < budget (salary/contractor cost under plan) |
|
||||
|
||||
The `status` field in variance responses is `"favourable"` or `"unfavourable"` based on this logic. It is not simply positive or negative variance — a cost account coming in -5% is favourable, while a revenue account coming in -5% is unfavourable.
|
||||
The `status` field in variance responses is `"favourable"` or `"unfavourable"` based on this logic. It is not simply positive or negative variance - a cost account coming in -5% is favourable, while a revenue account coming in -5% is unfavourable.
|
||||
|
||||
---
|
||||
|
||||
@@ -55,16 +55,16 @@ Accounts are typed to drive both P&L rollup structure and favourability logic.
|
||||
| Type | Description | `favour_high` |
|
||||
|---|---|---|
|
||||
| `revenue` | Top-line income | `true` |
|
||||
| `cogs` | Cost of Goods Sold — direct costs of delivering revenue | `false` |
|
||||
| `opex` | Operating expenses — Sales, Marketing, G&A, R&D | `false` |
|
||||
| `capex` | Capital expenditure — depreciable assets | `false` |
|
||||
| `cogs` | Cost of Goods Sold - direct costs of delivering revenue | `false` |
|
||||
| `opex` | Operating expenses - Sales, Marketing, G&A, R&D | `false` |
|
||||
| `capex` | Capital expenditure - depreciable assets | `false` |
|
||||
| `headcount` | Salaries, benefits, and contractor costs | `false` |
|
||||
|
||||
---
|
||||
|
||||
## Fiscal Periods
|
||||
|
||||
Periods are stored as integers 1–12, decoupled from calendar months. This means the schema supports fiscal years that start in any calendar month (e.g. a company with a July fiscal year start uses period 1 = July, period 12 = June).
|
||||
Periods are stored as integers 1-12, decoupled from calendar months. This means the schema supports fiscal years that start in any calendar month (e.g. a company with a July fiscal year start uses period 1 = July, period 12 = June).
|
||||
|
||||
When loading actuals from an ERP, map your ERP's period numbering to the engine's period integers at ingest time.
|
||||
|
||||
@@ -72,7 +72,7 @@ When loading actuals from an ERP, map your ERP's period numbering to the engine'
|
||||
|
||||
## Actuals Idempotency
|
||||
|
||||
The actuals ingest endpoint is idempotent by the combination of `(fiscal_year, fiscal_period, department_id, gl_account_id)`. Posting the same combination twice updates the amount — it does not create a duplicate row. This makes it safe to re-run ERP export feeds without needing to truncate and reload.
|
||||
The actuals ingest endpoint is idempotent by the combination of `(fiscal_year, fiscal_period, department_id, gl_account_id)`. Posting the same combination twice updates the amount - it does not create a duplicate row. This makes it safe to re-run ERP export feeds without needing to truncate and reload.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user