Company and master data in Dynamics 365 Business Central

The environment works from the previous station. This station is half the understanding of this product.

The question it answers is asked on every project, and in every interview: where did this account come from?

The rule before the detail

The product never asks the user for an account on any document.

A salesperson picks a customer, an item and a quantity and sees no account at all. The account is inferred from the intersection of two groups: a group on the partner and a group on the item.

That is the matrix.

What the record carries	Which side	What it meets
General business posting group	The customer or vendor	The general product posting group on the item
Customer posting group	The customer	The receivables account
Vendor posting group	The vendor	The payables account
Inventory posting group	The item	The stock account, crossed with the location
Tax business posting group	The customer or vendor	The tax product posting group on the item

Read the first and last rows together, because their structure is identical: a commercial side × an item side = one setup line carrying the accounts.

Anyone who understands that sentence understands this product in accounting terms. Anyone who does not reads the ledgers with no idea where their numbers came from, and fixes the error with a manual entry rather than fixing its cause.

The matrix in practice

Picture a “domestic” customer buying a “retail” item.

The intersection of the two groups produces a single line in the setup table, and that line carries: the sales account, the purchase account, the cost of goods sold account, and the discount accounts.

Every invoice between that customer and that item reads that line. Changing it changes the fate of every future invoice with one decision — that is the matrix’s power.

And it is simultaneously its danger: a missing intersection stops posting with an error message, and a wrong intersection posts quietly to an unintended account.

The second is far more dangerous than the first. An error that stops you is fixed in a minute; an error that passes is discovered at the close three months later.

The design rule — what separates a living project from an abandoned one

The number of setup lines = the number of partner groups × the number of item groups.

Four partner groups and five item groups produce twenty lines. Anyone creating ten groups on each side builds a hundred lines — all maintained, all reviewed at any change.

The rule: the smallest number of groups that achieves the distinction actually required.

One question decides whether a new group is created: do its transactions go to different accounts? If the answer is no, this is not a group; it is a dimension — the subject of the next section.

The commonest error here is creating groups on an organisational basis — one per branch, per representative, per segment — all of which go to the same accounts. The matrix multiplies with not one accounting distinction in return.

Dimensions — the alternative that prevents chart bloat

The question every project opens with: “we want to know the profit of each branch, each project and each product line.”

The wrong answer is adding a segment to the chart of accounts for each of them — turning a chart of two hundred accounts into two thousand, and making it unreadable and unmaintainable.

The right answer is a dimension.

A dimension is a tag hung on the entry — a department, a project, a region — and any report is filtered by it. The account stays one account, and the analysis runs on the dimension rather than on the account.

Two of them are “global”, meaning available for filtering almost everywhere, and those two are the ones chosen carefully, because the remaining dimensions stay available at less depth.

The working rule: department and project are the default choice for the two global dimensions at most companies. Anybody spending them on something of lower value pays for it in every report afterwards.

Set the dimension’s default value on the record — on the customer, on the item, on the account — not on the document. A dimension filled in by hand on every document is a dimension that gets forgotten, and a report built on a forgotten dimension produces an “unspecified” line that swallows half the numbers.

Number series — configured once and forgotten

Every document and every record takes its number from a defined series.

Configure them before you create anything. Changing the numbering pattern after a thousand documents leaves an archive with two patterns, and it is not fixable retrospectively.

The rule is simple: a short, comprehensible pattern an accountant can read, not a long code that explains everything and nobody reads.

The item card — two questions before any field

1. Is it an inventory item, a non-inventory item, or a service? That decides whether its quantity and value are tracked at all.

2. How is it costed? That is the whole of station six, and it is decided here rather than there — and changing it on an item with movement is not switching a field.

Everything beyond those two is filled when needed. A field filled because the screen displays it is a field maintained for ever at no return.

What you actually do at this station

• Draw the matrix on paper first with two partner groups and three item groups, writing the accounts at every intersection, then transfer it into the system. The order is deliberate.
• Create a customer and an item whose groups have no intersection, try to post an invoice, and read the error message. It is the most useful error message in the product.
• Change the sales account on a single line, post an invoice, and prove the entry followed the change.
• Design two dimensions with default values on the records, post five documents, and produce a report filtered by the dimension.
• Leave a dimension blank deliberately on one document, and see how it appears in the report. That lesson is not forgotten.

The three commonest errors

One: creating a group for every organisational classification. It multiplies the matrix with not one accounting distinction — and the remedy is a dimension, not a group.

Two: using the chart of accounts for what dimensions do. It produces a chart nobody reads and reports that can only be built with code.

Three: leaving dimensions with no default value. They are filled in the first month and forgotten in the second, and then a report is requested for a year half of which is untagged.

What the quality of this configuration does to implementation days and project cost is set out in the Dynamics 365 Business Central guide.

The acceptance test for this station

1. Draw the matrix from memory and explain what each intersection produces.
2. Explain when a need is a group and when it is a dimension, with the one question that separates them.
3. Diagnose an entry that went to an unexpected account and trace it to the setup line that caused it.
4. Design two global dimensions for a company with three branches and five projects, and justify your choice.
5. Calculate the number of setup lines for a design with four partner groups and six item groups, and say whether it is acceptable.

What comes next

You know where the account comes from. The next station moves the first money: the purchase cycle — and with it the peculiarity of this product that surprises anybody arriving from another: receipt and invoicing run from the same document, with independent quantities.