Three pieces of configuration decide how every transaction in Business Central is numbered, where it posts and how it is reported. Get them right in the Design phase and the system runs itself; get them wrong and every month-end is a reconciliation. What each one does, how to design them, and the mistakes that cost the most to fix later.
Ask a consultant what the hardest part of a Business Central implementation is and the honest answer is not manufacturing or warehousing. It is three setup tables that look trivial and decide everything: posting groups, number series and dimensions. They are designed in the Design phase, they are nearly impossible to change once there is data, and every transaction for the life of the system flows through them. This is what they do and how to design them.
Every time a sales invoice posts, Business Central has to decide which G/L accounts to hit: receivables, revenue, VAT, cost of sales, inventory, discounts. It does not store that on the invoice; it looks it up through posting groups.
Design rule: as few groups as the chart of accounts needs and no more. The temptation is a product posting group per product line "for reporting"; that is what dimensions are for. If two product groups post to the same accounts, they should be one group. Build the matrix in a spreadsheet with finance before anyone touches the system, fill in every cell, and load it.
Every document and master record gets its number from a number series: a code, a starting number, an ending number, an increment, optional starting dates for new ranges, and flags for manual numbers and date ordering. Series are attached in the setup pages (Sales & Receivables Setup for quotes, orders, invoices, posted invoices, credit memos; Purchases & Payables Setup likewise; Inventory Setup for items; and so on) and can also be set per customer or item template.
Design rules: a readable prefix per document type (SQ-, SO-, SI-, SCM-) so that a number tells you what it is; posted documents on their own series (you want posted invoice numbers to be gapless and sequential for VAT, which the order series is not); no manual numbers on anything posted; and no dates in the series unless the business genuinely resets numbering each year, because then someone has to remember to add next year's line every December. Leave room: a series that runs out in month ten of year three is a support ticket at the worst time. Multi-company: either shared conventions with a company prefix, or deliberately distinct, never accidentally overlapping.
A dimension is a tag on a transaction: DEPARTMENT, COSTCENTRE, PROJECT, REGION, PRODUCTLINE, whatever the business reports by. Two are global (stored as fields on every entry, filterable everywhere, usable in financial reports and as account schedule columns); six more are shortcut (available on documents and journals); any number beyond that are stored in the dimension set but only reachable by analysis views. Dimensions replace the NAV-era habit of encoding analysis in the chart of accounts (7100-01, 7100-02) and the product-posting-group-per-product-line habit above.
Design rules: pick the two global dimensions carefully, because changing them later is a full reposting exercise: they are the two the board reports by, usually department or cost centre and one other. Set default dimensions on accounts, customers, items and resources with Value Posting = Code Mandatory where the dimension must be present, so that users are not asked for it and cannot forget it. Use dimension combinations to block nonsense (a sales department on a purchase account). Keep the value lists short and owned by finance. And design the financial reports (row and column definitions) at the same time, because the dimensions exist to feed them.
All six are Design-phase decisions and all six are cheap there. They are also the first thing we look at in a health check of an existing system, because they explain most of what a finance team is working around. The data migration post covers the "redesign the chart, don't copy it" argument in more detail.
