A customer pays for the part at the counter, but that payment does not really land in the books until someone reconciles it later. Multiply that by three registers, two stores, and a mix of cash, card, and standing deposits, and the gap between what happened at the counter and what shows up in the general ledger widens fast. The last hour of every shift goes to matching receipts against a cash drawer instead of preparing for the next customer.
Why Does Payment Reconciliation Break Down at the Counter in Business Central?
Microsoft Dynamics 365 Business Central was built for office-based receivables, not a trade desk running several registers at once. A sales order and its payment are posted together, but nothing in the standard flow tells you which register, which store, or which cashier actually took that cash or card. Every store ends up posting to the same balancing account, so a mismatch at one location is buried in the same pile as every other location’s activity.
Deposits compound the problem. Standard prepayments were not designed for the layaway-style deposits common at a parts counter, where a customer might put money down weekly against a special order. Left unmanaged, those partial payments blur into regular customer aging, making it harder to tell what is a deposit and what is an open invoice. This is not a minor bookkeeping nuisance. Retail error and process failures are a real driver of loss: the National Retail Federation’s National Retail Security Survey found that shrink reached $112.1 billion in 2022, with internal process and accounting errors a meaningful share of that figure, alongside theft. A counter that cannot easily tell what it took in, by register, by store, is a counter that cannot easily catch its own mistakes.
What Is Counter Sales?
Counter Sales is a point-of-sale and trade-desk order entry application built directly into Business Central. It extends the standard sales order and payment journal so a professional salesperson at a parts counter or trade desk can search for items, scan barcodes, take payment, and post everything without leaving the Business Central interface. Rather than bolting on a separate cash register system, it lets payment activity flow straight into the accounts you already reconcile against.
How Does Counter Sales Handle Payments Across Stores and Registers?
Payment providers are now defined as payment networks, and each store, or even each individual register, can run its own network. That means a downtown counter and a warehouse trade desk can each use the card processor and terminal that suits their volume, without one setup forcing a compromise on the other. Each payment method can also post to a different balancing account by store, so a discrepancy at one register shows up against that register’s own account instead of getting lost in a shared total. Store and user-level limits on which payment and cashback methods are available keep staff from selecting an option that store was never set up to handle.
Before anything posts, the payment journal test report lets staff review the day’s entries and catch a mis-keyed amount or a payment applied to the wrong line. That kind of pre-post review is the same principle Business Central’s own payment reconciliation journal test report applies to bank statement matching, just moved to the counter where the transaction actually happens. Deposits now post to their own customer posting group, so a layaway payment on a special-order stays separate from regular account activity instead of muddying the customer’s aging. When a customer needs proof of what they paid, staff can reprint a posted receipt straight from the payment entries, the customer ledger entries, or the post-and-print action, without hunting through old batches.
Why Does This Matter for Partners and End Users?
For the counter staff and store managers using it daily, this means less time spent chasing a shortfall back through yesterday’s transactions and more confidence that the numbers on the drawer match the numbers in Business Central. For Microsoft Partners, it is a deployable answer to a request that comes up constantly among distribution and trade clients: a way to run multi-store, multi-register payment processing without layering on a separate point-of-sale platform and the reconciliation headaches that come with two systems trying to agree on the same numbers.
See It in Business Central
Details on Counter Sales, including how payment networks, deposit posting groups, and the payment journal test report fit together, are available at CounterSalesForDynamics.com. If you are evaluating this for your own counter or trade desk, a Microsoft Partner can walk through setup and what a deployment would look like for your stores.