Worked Example · Reconciliation · Product: Lens

Every brand matched to the cent. The totals were 292,808.81 apart.

Ember & Oud is our sandbox: a fictional Dubai restaurant group running six brands out of a single central kitchen. Oak & Marble is the premium grill; Blaze Wing is the volume business; Clawpoint, Rolling Twentytwo, Frankly Dogs and Verde Blends fill out the portfolio. Fourteen outlets, one finance team, all on Business Central.

A growth investor's diligence list arrived on Tuesday. Item four: revenue by brand, year to date, tied to the general ledger.

Two people answered it, because two people had the access. Amira runs finance for the group and works in Lens; she built the brand table for the board pack. Karim is the group's Business Central partner, has maintained the ledger since go-live, and has no Lens login. The CFO asked for the ledger-side schedule. Neither knew the other had been asked.

What Amira sent: four controls, one page

Lens revenue view grouped by business group, showing six brands and a seventh row — Open Revenue, switch to Yearly, set thru to February, group by business group. Six brands, and a seventh row.

Both schedules landed in the data room on Thursday. Line by line they were identical: Blaze Wing 2,569,974.06, Oak & Marble 2,109,713.48, and so on down all six brands, to the cent, produced by two people who had not spoken. Then the totals disagreed by 292,808.81, and neither schedule had an obvious mistake in it.

Two hundred and ninety-two thousand dirhams is not a rounding difference, and it is not a timing difference either: both schedules were run against the same closed period, in the same company. It is not spread across the brands, because every brand line agrees exactly, which rules out a rate, a currency conversion, and a different definition of revenue. Whatever it is, it is one thing, sitting somewhere that only one of the two views can see.

The question that went back to both of them

Same ledger, same period, same six brands to the cent. So where does 292,808.81 come from, and which schedule goes in the data room?

The chart of accounts has an account for every brand. All six are empty.

Karim's route is the long one, and it is where the difference comes from, so it is worth walking in full. The obvious first move is the wrong one, and it is signposted. Filter the chart to the revenue range and there they are: Sales - Blaze Wing, Sales - Oak & Marble, Sales - Clawpoint, and one for each remaining brand. Not one of them carries a balance. Every dirham of food sales posts to a single account, 41100100 Food Sales - Consolidated, at −7,608,234.26.

Six brand-named revenue accounts, all blank, above the one account that holds the money. Nothing here is misconfigured. Accounts answer what was sold; dimensions answer who sold it and where.

So brand is a dimension, carried on the ledger entry rather than the account. Then the natural page turns out to be a dead end. G/L Balance by Dimension is where this analysis belongs, and its Show as Lines lookup offers exactly three choices: Business Unit, G/L Account, Period. BRAND is not among them, and no amount of filtering puts it there. The reason is one screen away, in General Ledger Setup.

General Ledger Setup with both Global Dimension code fields blank — General Ledger Setup, Dimensions. Both Global Dimension codes are blank. That single fact is what closes the natural route.

Why only some dimensions get an axis

Global 1 to 2

Written onto every ledger entry. These are the only two that appear as an axis on the standard analysis pages.

Shortcut 3 to 8

Available on document and journal lines, but not carried as their own column on the entry.

Everything else

Stored as dimension set entries. Correct on every posting, and invisible to the pages that want an axis.

Ember & Oud has both globals blank, so BRAND sits in the third tier. Promoting it to global would fix this permanently, and it is a company-wide change that touches every entry, which is not something a finance lead does on a Thursday to answer one question. The reporting question had a prerequisite. It had to become a configuration change first.

The question could not be asked until the setup changed

An Analysis View is the sanctioned way to put a non-global dimension on an axis. Karim created one: code BRANDYTD, Dimension 1 Code BRAND. Three of the card's defaults decide what happens next.

Analysis View card BRANDYTD with Last Date Updated empty and Last Entry No. zero — Account Source G/L Account, Account Filter blank, Date Compression Day, Dimension 1 Code BRAND. And the tell, top right: Last Date Updated is empty and Last Entry No. is 0. The view exists and contains nothing at all.

An Analysis View is not a saved query

Update walks the general ledger and materializes it into Analysis View Entry rows, pre-sliced by the four dimensions named on the card. That has three consequences worth knowing before you rely on one: it is stale until updated, unless Update on Posting is switched on; Date Compression is baked into the stored rows, not applied when you read them; and the dimension list is fixed at creation.

Three ways to get the pivot wrong. All three fail silently.

1
It is keyed by the code. Typing the description "Brand" into Show as Lines clears the field and leaves the placeholder behind. The axis wants BRAND.
2
Tab commits; Enter does not. Enter re-opens the lookup and discards the entry. The matrix still renders: it is just the previous pivot, and nothing says so.
3
Day compression, 59 columns. A two-month window came back one column per day. The figure anyone wants is Total Amount, on the far left of the grid.

The near miss: Account Filter left blank

Analysis by Dimensions matrix with no account filter, totals running roughly 4.5 times low — No filter: revenue, cost of goods and opex netted together.

The same matrix with the revenue account range applied, matching the Lens figures — With 41100000..41999999 applied: six brands, matching to the dirham.

Account Source is G/L Account and nothing narrowed it, so Total Amount is revenue, cost of goods and operating expense netted together. They run roughly 4.5 times low, but at no consistent ratio, between 4.38 and 4.68, so checking one brand against a number you half remember does not catch it.

The filter that makes it revenue: 41100000..41999999, covering Food Sales, Other Operating Revenue and Sales Adjustments. Set it on the matrix page rather than the card and no re-Update is needed. Business Central reports revenue as credits, so the column comes back negative. With the range applied, Karim's six brands matched Amira's exactly. The totals still did not.

Both schedules were right. Only one of them showed the gap.

Two people, two completely different routes through the same ledger, agreeing on every brand to the dirham. That agreement is not the interesting part. The seventh row is: the revenue that carries no BRAND dimension at all, which Lens shows by default and which a dimension matrix has no row for, because a matrix pivots on values that exist.

The six numbers were never the risk. The row that was not there was.

The same sandbox, four questions later

The companion worked example picks up in February: a wall of green on the dashboard, a 453.5 point swing on a row that is not a brand, and four questions that end with Claude qualifying its own number on the MCP server.

Read the Investigate worked example →

Download this worked example as a PDF (4 pages)

Secure, and in Your Control

Sign in with Microsoft·Read-only, never writes to Business Central·Runs in your own cloud region·Daily sync, unlimited users

Figures shown for illustration.