What the integration needs to do
The POS may need to send:
Business Central may need to provide:
- Items and variants
- Prices
- Stock
- Customers
- Customer-specific pricing
- Salespeople
- Accounts
- Dimensions
- Sales
- Orders
- Customers
- Returns
- Other retail transactions
Business Central may need to provide:
- Items and variants
- Prices
- Stock
- Customers
- Customer-specific pricing
- Salespeople
- Accounts
- Dimensions
The POS may need to send:
- Sales
- Orders
- Customers
- Returns
- Other retail transactions
Three common integration models
1. Standalone POS with an integration layer
An independent POS maintains its own structures and an integration transfers relevant information to and from Business Central.
The advantage is choice.
The trade-off is another operational component.
You need answers to:
- Who owns master data?
- How often does data move?
- How are errors detected?
- How do retries work?
- How are duplicates prevented?
- Who monitors the integration?
- Who takes the first support call?
2. Custom integration
A retailer or partner may create a custom connection. This can make sense when requirements are unusual or an existing POS cannot easily be replaced. The advantage is flexibility. The trade-off is lifecycle ownership.
- Who owns the code?
- Who documents it?
- Who tests it after upgrades?
- Who maintains it when APIs change?
- What happens if the original developer disappears?
The real cost of custom integration is not only building it.
It is owning it afterwards.
3. POS designed specifically for Business Central
The third approach is a POS built around Business Central from the beginning.
POS365 follows this model. It is built only for Business Central, while remaining a separate Windows POS application. Business Central acts as the core system and source of truth. The distinction is not that no data moves. The distinction is that the Business Central relationship is part of the product architecture rather than an ERP integration added to a general-purpose POS afterwards.
Imagine this situation
Before go-live, document for every important process:
- Source system
- Sestination system
- System of record
- Expected timing
- Failure detection
- First-line investigation
- Escalation owner
Do not discover your support model during an incident.
What commonly goes wrong?
01 — Unclear master-data ownership
Prices can be changed in two places, which value wins?
02 — Inventory disagreement
One system says an item is available and another does not, the integration problem becomes a customer-service problem.
03 — Silent transaction failures
Failed transaction is manageable when somebody knows about it. Silent failures are more dangerous.
04 — Duplicate processing
Retries improve resilience only if they cannot accidentally create the same transaction twice.
05 — Online-only assumptions
The store must continue selling during an outage, test the actual offline workflows.
06 — Custom requirements discovered too late Prices, sales orders, special orders, prepayments, serial numbers, payments and industry-specific processes can materially change implementation scope. Validate them early.
Define the system of record
Most integration problems become easier to prevent when every important data object has a clearly defined owner. Before configuration begins, decide which system is authoritative for each part of the retail operation.
Before configuration starts, define ownership for:
Test your own environment
A vendor demo proves the product can work.
It does not prove the solution will work with your Business Central setup.
Extensions, dimensions, pricing, item structure, tax configuration, payment providers and operational workflows can all matter.
POS365 prospects can test against their own Business Central environment before committing.
Regardless of product, test the environment you intend to operate.
POS-to-Business Central go-live checklist
Before going live, test the complete retail flow, from data and transactions to connectivity and hardware.
Data & setup
- Item creation and changes
- Price changes
- Variants
- Inventory by location
- Customers
- Customer-specific prices
- Tax / VAT
Transactions & workflows
- Normal sales
- Business Central posting
- Stock consequences
- Discounts
- Payments
- Returns
- Parked transactions
- Sales orders
- Quotes
- Special orders
- Prepayments
- Serial-number workflows
Resilience & hardware
- Internet loss
- Reconnection
- Failure detection
- Retries
- Duplicate prevention
- Printers
- Payment hardware
- Store-specific configuration
Confirm operational readiness
The best integration eventually becomes boring
The best integration eventually becomes boring
Products appear where expected. Prices are right. Sales arrive. Inventory can be trusted. Failures are visible. Staff know who to call. Nobody spends every morning wondering whether yesterday’s transactions synchronized.
That is the standard a POS-to-Business Central integration should be judged against.
Not: Can the systems connect?
But: What will we still have to integrate, monitor and own after go-live?
