A store counts 21 individual blind boxes at closing, and its POS also shows 21. ERP shows two PDQ display packs. If that SKU has twelve individual boxes per pack, ERP appears to hold three more units than the store—and the store sold three that day. Before choosing between a conversion error and a missing sales update, align the product, location, inventory state and cutoff. The first point at which the records diverge determines what to investigate.
Collectible toys may be received in PDQ packs or full boxes and sold as individual units. Store managers see goods available on the shelf; ERP may display balances in purchasing or warehouse units. Asking staff to post a count adjustment, or retransmitting every stock balance, can conceal the problem until the next unpacking or sale.
Make sure all three records describe the same goods
Choose one repeatedly affected SKU and one store. Obtain a physical count, the POS stock ledger and ERP inventory detail for the same day. If either system provides only a summary balance, obtain the underlying receipt, unpacking, sales, return, transfer and count-adjustment documents.
Align four dimensions before comparing quantities:
- Product: reconcile the same SKU and its packaging codes. Do not treat a pack and its contents as unrelated goods or combine different series or variants.
- Location: distinguish the store, local fulfillment stock and unattended devices. Do not count a transfer in transit at both ends.
- Status: separate physical stock, available stock, reservations and damaged goods awaiting treatment.
- Time: use one cutoff and state whether daily closing and ERP posting have completed.
Convert to individual units using the confirmed ratio for that SKU. If ERP displays “2 PDQ,” inspect the underlying balance and display rules. The screen might show only whole packs or convert a unit-level balance for presentation. An integer on the screen alone does not prove a posting error.
Preserve unopened and opened states even after quantities are normalized. Using a common unit for reconciliation does not make an unopened pack available for individual-unit sales.
Find the first divergent document
Place store and ERP movements in business-event order and identify the last point at which they agreed. The first event after that point is usually more informative than a month-end difference.
| Observed pattern | First evidence to inspect | Possible explanation |
|---|---|---|
| The difference starts at receipt or unpacking and resembles a pack quantity | Unit relationships, receiving unit, unpacking document and deduction of the original pack | Wrong ratio, duplicate counting or an unrecorded unpacking event |
| Opening balances match, then ERP exceeds POS by one for every unit sold | POS sales, outbound messages and ERP stock postings | A transaction was not sent, not received or not posted after receipt |
| The difference begins after a return, transfer or count and persists | Document states, approval times and both transfer endpoints | A document completed on only one side or was processed under different states |
| The difference disappears after closing or batch processing | Balance timestamps and interface cycles | Different reporting cutoffs; check whether the delay is within the agreed window |
These patterns identify a starting point, not a final diagnosis. Two causes can coexist: an unpacking error may omit twelve units, followed by three missing sales updates. Reconstruct the sequence and resolve each cause separately.
If the difference starts at receipt or unpacking, check units
Product master data must define the PDQ, full box and individual unit for that product: how many smaller units each contains, which level can be sold independently and which level the store receives. Different series can have different pack quantities. Do not turn one SKU's twelve-unit ratio into a universal rule. When packaging changes, establish which version applies to older stock and unfinished documents.
Then follow the physical action. If unopened packs and loose units are managed separately, opening one twelve-unit PDQ should reduce unopened packs by one and increase individual units by twelve. If the base unit is already the individual box, total quantity remains twelve while the state changes from unopened to opened. Neither model should make both the outer pack and its contents available as additional stock. A physical unpacking with no corresponding record can also separate the count from the ledger.
Check what ERP actually receives: the original receiving unit, a conversion document, a post-unpacking balance or a movement in the smallest sales unit. If both systems convert data, establish exactly where conversion occurs so one transaction is not converted twice. Opening balances during a migration require their own unit-model validation; this investigation concerns ongoing reconciliation after launch.
If the gap grows with sales, trace actual ERP posting
When opening balances agree and diverge one sale at a time, do not begin by changing the ratio. Take one completed transaction through the entire sequence: store sale and stock deduction, creation of outbound data, interface transmission and receipt, then ERP validation and posting. At every step, match the store, SKU, transaction or document reference, quantity, unit, event time and result.
“Sent” establishes that the store system transmitted a message. “Received” still does not establish that ERP updated store inventory. A product mapping error, an ERP document awaiting approval or a quantity unit incompatible with the target field can leave a message received without a stock posting. If a void or return follows the sale, verify the reversal and receipt against the original transaction relationship.
Retransmit only the documents confirmed missing, and verify that retries cannot deduct stock twice. Where a posting exists but a report is stale, investigate reporting definitions and refresh times. Before any whole-store balance replacement, retain snapshots from both systems and the discrepancy records. Otherwise, missing or duplicate transactions can disappear behind the new total.
Worked example: 21 units in store, 24 in ERP
The store receives two PDQ packs containing twelve individual boxes each: 24 units. It opens one pack and sells three units. Closing physical stock is one unopened pack plus nine individual boxes, or 21 units. POS agrees with the count, while ERP still displays two PDQ for the same store and product, apparently equivalent to 24 units.
First establish whether the ERP figure is the current closing balance or a snapshot taken before sales updates. Then follow the evidence:
- If ERP's underlying balance is already 21 units but the screen still shows two packs, inspect the report's cutoff and display rules.
- If the underlying balance is 24, locate the three sales. If POS recorded and deducted them but no matching interface transaction exists, investigate the sending step.
- If receipt is confirmed but ERP has no stock deduction, inspect ERP validation and posting.
- If ERP contains the deduction but still closes at 24, check for receipts, returns or adjustments that offset it during the period.
- If POS also shows 24 while the physical count is 21, return first to store sales, unpacking and count evidence.
The decision is therefore driven by the first divergent event, not a guess between two familiar causes. Store operations verifies physical goods and actions, the product owner confirms codes and unit rules, and interface and ERP owners verify message and posting records respectively.
Make discrepancies traceable daily exceptions
A recurring problem often persists because someone can identify the total difference but not the transaction that caused it. Assign the inventory record owner for each operating location and define the documents owned by POS, ERP and warehousing. Generate exceptions against the same SKU, store, smallest unit, status and cutoff.
Retain the first appearance, linked documents, quantity difference, owner and resolution. Carry unresolved exceptions forward rather than replacing yesterday's unexplained cause with today's closing balance.
The PEKON Smart Retail System covers store products, transactions and inventory and can integrate with ERP. PEKON's collectible toy retail solution describes PDQ-to-unit conversion. Each project must still confirm the actual units, inventory system of record, message direction, synchronization cycle, recovery process and responsibilities, then demonstrate the agreed ERP posting. A statement that conversion is supported does not establish that every existing ERP will automatically post the same unit.
A worksheet for the first discrepancy
Use one product and one store to collect the original evidence. Preserve the values at the time of the discrepancy instead of replacing them with corrected totals.
| Check | Record |
|---|---|
| SKU and units | Product code/barcode; larger and base units; SKU-specific conversion ratio and effective version |
| Location and inventory scope | Store and warehouse codes; physical count location; total or available quantity; treatment of reserved, damaged and in-transit goods |
| Cutoffs and balances | POS and ERP extraction times, units and balances; agreed synchronization cutoff; normalized difference |
| First divergent document | Last matching time; first divergence time, event type, document number and movement quantity; supporting physical or count evidence |
| Transmission and posting | POS deduction; send, receipt and failure records; ERP validation, posting or approval state; retry deduplication key and result |
| Resolution and review | Cause, remedy, owner, completion time and correction document; verified physical, POS and ERP balances |
For a practical evaluation, bring the product's packaging rules, two days of stock movements and one discrepancy document. The outcome should identify a specific product, place, state and business event—not merely establish that two systems display different numbers.
FAQ
Does a fractional PDQ balance prove an inventory error?
No. ERP may store individual units and display an equivalent number of PDQ packs. If one pack contains twelve units, 21 units equal 1.75 packs. If ERP cannot represent that balance, agree how sealed packs and remaining individual units are recorded and displayed.
Which figure should be trusted when the physical count, POS and ERP all differ?
Pause direct adjustments and preserve a count and transaction histories at the same cutoff. The count establishes what is present; POS and ERP documents explain movements. Align reserved, damaged and in-transit quantities, then find the last match and first divergence before deciding on a missing entry, status correction or approved adjustment.
If only one store has repeated variances, is the interface at fault?
Check that store’s receiving, unpacking, device sales and counting processes, then location codes and product mappings. Treat it as an interface issue only when the relevant transmission, receipt or posting evidence supports that diagnosis. Other stores being correct does not prove this store’s unit rules are correct.
Will synchronizing the inventory balance every day solve the problem?
An overwrite may temporarily align the totals but cannot explain missing sales, duplicate postings or incomplete transfers. Repair documents and unit rules first. Where a balance adjustment is necessary, retain original snapshots, the cause and approval history.