Platform · financial core

Reporting your accounting system cannot produce

Department P&L is the single most common reason a company starts shopping for a new ERP. It is also achievable without replacing anything, provided the dimensions are carried on the journal line instead of being reconstructed in a spreadsheet every month.

See your own P&L by department

Connect read-only and we will produce the dimensional reporting your current system cannot, usually within a week.

1 / 3
Any dimension combinationWorks on your current ledgerExports to your warehouse
Rows
DeliverySalesG&A
New York$412K$286K$104K
Austin$238K$141K$62K
Remote$176K$88K$39K
Every dimension is on the journal line, so any combination is a query rather than a rebuild.

What you get

Six families of report.

Statements

P&L, balance sheet, cash flow, trial balance, and GL detail — by entity, consolidated, or any dimension combination, with comparatives and budget columns.

Consolidated and by entity

Roll-ups with intercompany elimination, minority interest, and currency translation, plus the ability to drill from a consolidated line into the entity that produced it.

Management reporting

Department and location P&L, project and client margin, revenue per head, and the operational metrics that only work when dimensions are on the line rather than approximated.

Variance and flux

Period over period, actual against budget or forecast, with the movement explained by the transactions that caused it rather than left as a number to investigate.

Delivery anywhere

Scheduled email, Excel and CSV export, a live API, and direct sync into Snowflake or BigQuery. A report you can only view in our interface is a dependency.

Narrative drafts

The CFO agent drafts the commentary for a board pack from the actual variances, which you edit rather than write from a blank page.

Why most companies cannot produce this today

It is almost never a reporting-tool problem. It is that the dimensions were never captured on the transaction, so no tool downstream can recover them. A bill coded to 6420 with no department is a bill with no department, and the monthly spreadsheet that assigns one is somebody guessing consistently.

Three things have to be true for dimensional reporting to work, and most mid-market companies have none of them:

  • Dimensions exist as dimensions, not encoded into the account number or into a class field doing three jobs at once.
  • They are required at posting rather than optional, because a dimension that can be blank will be blank and a report silently missing twelve percent of transactions is worse than no report.
  • They are applied consistently across manual entries, AP, payroll, and the integrations — which is where most implementations quietly fail, because payroll lands as a single lump entry with no department at all.
A report that silently excludes twelve percent of transactions is worse than no report, because someone will act on it.

The payroll journal is where it usually breaks

Worth calling out specifically. Labour is the largest cost in most service businesses, and it typically enters the ledger as one summarised journal from the payroll provider with no department, location, or project on it.

That single gap makes department P&L impossible no matter how well everything else is coded. Mapping payroll to dimensions at the employee level — which is a mapping exercise, not a technical one — is frequently the highest-value hour in an entire engagement.

You do not need a new ledger for this

This is the case we make most often and it is the honest one. Where your accounting system holds the data but cannot dimension it, we read it into the business graph, add the dimensions that are recoverable, and produce the reporting from there. Where the dimensions genuinely were never captured, no system can invent them and we will tell you that the fix is at the point of entry rather than at the point of reporting.

What we cannot recover

Two years of history coded without department cannot be dimensioned retrospectively with any integrity. We can apply a mapping where one is defensible — vendor to department, employee to cost centre — and we will say clearly which figures are derived rather than captured, because presenting the two identically is how a report stops being trustworthy.

Questions

What finance teams ask.

Can we get department P&L without leaving QuickBooks?
Usually yes, if the data is recoverable. We read QuickBooks into the graph and produce the reporting there. Where the dimension was never captured — payroll being the common case — the fix is at entry, and we will tell you which of the two you have.
How many dimensions can we use?
Entity, department, location, class, project, and customer as standard, with additional custom dimensions available. More than about six becomes unusable in practice regardless of what a system supports.
Does it handle allocations?
Yes — overhead allocation across departments or entities using a method you configure, applied as real journal entries rather than as a reporting-layer adjustment, so the allocated numbers tie to the ledger.
Can we build our own reports?
Yes, and export them. Saved views, scheduled delivery, an API, and warehouse sync. We would rather your analysts work in the tool they prefer than force everything through ours.
What about consolidated reporting across entities?
Full consolidation with intercompany elimination and currency translation, with drill-down from a consolidated line into the contributing entity.

Get the P&L your system will not give you.

Read-only connection, about a week, and you see whether the dimensions are recoverable from what you already have.