Analytic accounting

Analytic accounting is the parallel structure to the chart of accounts that lets you track where money is spent and earned by cost centre, project, department, or any other dimension you care about — independently of the legal chart.

The two structures

Legal (financial)	Analytic
GL accounts: 1xx-9xx	Analytic accounts: free-form names
Required by the regulator	Optional, for management
Same for every Bulgarian business	Specific to your management view
Aggregates to the balance sheet + P&L	Aggregates to "profitability by X" reports

Every journal entry posts to a legal account. Optionally, it also carries an analytic distribution — which says "this expense was for Project A, this revenue from the Sofia branch".

When you want analytic

• You run projects and want per-project profitability
• You have multiple departments / branches and want a P&L per department
• You track marketing spend by campaign
• You manage cost centres at the executive level
• You bill customers based on time / cost (Project app + timesheets)

If your business is a single shop with one revenue stream, you can ignore analytic accounting — the legal P&L tells you what you need.

The structure

Analytic accounts can be nested:

- Headquarters
  - Marketing
    - Online ads
    - Trade fairs
  - Operations
    - Warehouse Sofia
    - Warehouse Plovdiv
  - Sales
    - Domestic
    - Export
- Project: Acme Implementation
  - Phase 1 — Discovery
  - Phase 2 — Build

You define the structure in Accounting → Configuration → Analytic Accounts.

Applying analytic to transactions

Two patterns:

Pattern A — Per-line analytic distribution

On any invoice / bill line, set an Analytic Distribution:

Account	Percentage
Marketing → Online ads	80%
Marketing → Trade fairs	20%

PLANA splits the line's value across the analytic accounts you chose. Most common for shared costs (a software subscription used by multiple projects).

Pattern B — Automatic from a related record

A project's timesheet entries auto-distribute to the project's analytic account. A sale order with an analytic account auto-passes it to the invoices generated from it.

This is the cleaner pattern when your records already carry the right analytic.

Analytic plans

For multi-dimensional analytic (e.g. "Department × Branch"), define analytic plans — each plan is one dimension. A transaction can carry one analytic account from each plan:

Plan	Example
Department	Sales / Marketing / Operations
Branch	Sofia / Plovdiv
Project	Project A / Project B / Internal

A sale of widgets at Sofia branch attributable to Project A carries: Department=Sales, Branch=Sofia, Project=Project A. Reports can group by any combination.

Reports

Report	What
Analytic Items	Every line that hits an analytic account
Analytic Account Balance	Net by analytic account for a period
Project Profitability	(Pro+ tier) per-project P&L using project's analytic

Each report drills down to source transactions.

Project P&L example

For each project (using the Project app):

Revenue	Expense	Margin
Customer invoices linked to the project	Timesheet costs + direct material purchases linked to the project	Revenue – Expense

The project's analytic account aggregates everything. A glance tells you which projects are profitable.

Limits

• Analytic doesn't affect the legal P&L — it's parallel
• A transaction with an analytic distribution still posts to a single GL account
• Analytic balances don't tie to the GL the way the chart of accounts does — analytic is for management; GL is for the regulator

Where to read more

• Chart of accounts — the legal parallel
• Project → Customer billing — analytic drives project invoicing
• Reports
• Customer invoicing — assigning analytic on invoice lines