Mapping LS Central stores to Business Central posting groups

Posting & finance · 7 min read

Two stores, same items, same prices — but head office wants their sales reported separately, and month-end shows one blended pile. The usual cause is not a reporting problem. It is one field, set once during implementation and never looked at again: the Gen. Bus. Posting Group carried by each store. This guide covers what that field actually controls, where the related defaults live, and how to audit the mapping before it quietly merges stores that should stay apart. Posting setup decides where money lands in the ledger; treat the changes below as accounting setup work, not professional accounting advice.

The one field that routes a store's sales

Business Central does not post a sale to "the sales account." It looks up a combination. The General Posting Setup page is a matrix that combines a general business posting group with a general product posting group, and each combination determines the accounts used for sales and purchases, credit memos, prepayments, invoice and payment discounts, cost of goods sold, and inventory adjustments. The business side of that combination answers "who is selling or buying"; the product side answers "what is being sold."

On a normal sales document, the business side comes from the customer: the Customer Card's Invoicing FastTab carries the Gen. Business Posting Group, the VAT Business Posting Group, and the Customer Posting Group, and those groups carry over automatically to documents. A POS sale has no named customer in that sense — the store stands in for the selling side. That is why LS Central stores themselves carry a Gen. Business Posting Group value: LS Retail's own release notes record the DOMESTIC group being added to individual hotel stores, and LS Central demo data was aligned with Business Central demo data so the DOMESTIC group replaced NATIONAL across items, vendors, and customers. When the store's statements post, the store's group is the business half of every lookup those sales make.

What the store's group controls — and what it does not

Keep the boundaries straight, because most mapping mistakes come from expecting one field to do another field's job:

• Revenue, COGS, and discount accounts: yes. The sales account for a line is determined by the combination of the business group and the item's Gen. Product Posting Group. Microsoft's own training material makes the point directly: the same item can post to different sales accounts because the selling side carries a different general business posting group.
• Receivables: no, that is the Customer Posting Group. It sits next to the business group on the customer card and controls the receivables side. POS sales settled in cash or by card at the till do not become receivables in the first place, which is why tender setup, not this field, decides where the money side lands.
• Inventory valuation: no, that is location-driven. An item's Inventory Posting Group works together with the location code in Inventory Posting Setup to determine the inventory accounts. Two stores can share a business group and still hold inventory in separate locations — and the reverse is also true.
• Tax: separate matrix. VAT routing follows the VAT business and product posting groups through VAT Posting Setup. Changing a store's general business group to fix a tax problem is aiming at the wrong table.

Where the defaults live, on both sides

Three places, checked in this order when a store posts somewhere unexpected:

1. The store setup in LS Central. The store's own Gen. Bus. Posting Group value. If it is wrong here, every statement that store posts inherits the error.
2. The General Posting Setup matrix in Business Central. One line per business-group and product-group combination the stores will actually use. A combination that does not exist fails at posting time — Business Central raises an error when a transaction tries to use a missing combination, which is the loud version of this problem. Also keep the catch-all lines: a line for each product group with a blank business group, used for activity with no customer or vendor attached, such as item journals.
3. The item side. Each retail item's Gen. Product Posting Group. A store mapping can be perfect and still surprise you if two departments' items share a product group that was supposed to split them.

The mapping worksheet for multi-store setups

Before changing anything, write the current state down. One row per store, five columns:

• Store — the LS Central store code and name.
• Current Gen. Bus. Posting Group — copied from the store setup, not from memory.
• Reporting unit it should feed — the store, region, or banner its sales must be separable as in the ledger.
• Product groups sold — the Gen. Product Posting Groups its items use.
• Matrix check — for each product group in column four, does a General Posting Setup line exist for this store's business group? Yes or no, per row.

The decision rule the worksheet enforces: stores share a business group only when head office genuinely wants their sales indistinguishable in the ledger. Sharing is not a shortcut; it is a reporting decision. If two stores need separate revenue, separate COGS, or a clean per-store margin, they need separate groups — or a deliberate decision to separate them by dimension or location instead, written down so the next person does not "fix" it.

What breaks when two stores share the wrong group

• Per-store revenue disappears. Both stores' sales post through the same combinations to the same sales accounts. The ledger cannot un-mix them afterwards; you are left reconstructing store totals from transaction data instead of reading them from the G/L.
• COGS blends with it. Cost of goods sold is one of the accounts the combination determines, so store-level margin reporting is wrong in both directions at once.
• Discount visibility blends too. Invoice and payment discount accounts are also set per combination, so a promotion run in one store pollutes the other's discount picture.
• Nothing errors. This is the dangerous part. A missing combination fails loudly at posting; a wrong-but-existing combination posts cleanly, every day, until someone reconciles. (If statements are new to you, see our end-of-day statement routine first.)

Procedure: audit and fix a store mapping

1. Build the worksheet above from the live setup: store groups from LS Central store setup, product groups from the retail items each store sells.
2. Compare against the reporting requirement. Mark every pair of stores that share a business group but must report separately.
3. Create the new business group if one is needed, then add its General Posting Setup lines for every product group from the worksheet — sales, COGS, and discount accounts included — before touching the store.
4. Change the store's Gen. Bus. Posting Group to the new group. Do this between statement periods, never mid-day: statements are created per store for a transaction date range and then calculated and posted, so a clean break falls between one posted statement and the next.
5. Post one statement for the changed store and trace its sales lines to the G/L: confirm the revenue and COGS landed on the new combination's accounts.
6. Repeat per store, one at a time, so a bad line is attributable to the change you just made and not to a batch of five.

What success looks like

After the fix, a posted statement for the changed store produces G/L entries on the sales and COGS accounts named in the new business group's General Posting Setup lines; the other store's entries are unchanged; and filtering the sales account by the two business groups now separates the stores cleanly. If any line still lands on the old accounts, the worksheet missed a product group — check the item side before assuming the store change did not take.