Online sale refunded in store: reconcile both systems

Link the web order, in-store return, stock movement and payment refund before making corrections in both systems. Decide which system will issue the refund and which records will synchronise automatically. Then check the other channel for a duplicate action. A returned item, a credited sale and money sent back to the customer are separate events that need shared references.

Once the return remedy is approved, keep a trail that staff in both the online store and physical shop can follow.

Identify the original sale and current refund status

Find the web order and payment ID, check the amount already refunded and record the store handling the return. Ask whether another staff member or an automated process has already submitted a refund. A payment marked pending refund should not trigger another payment from the till.

Check the actual product and plan before using a cross-location feature. Square's Australian returns guide restricts returns across locations to Retail Plus and Premium. A feature allowing an unlinked refund does not prove that a separate web platform will update its order or stock automatically.

Follow the shared references through both systems

Event	Web system	Store and accounts
Original $140 sale	WEB-82 and PAY-82	Original sale export IMP-82
One item accepted for return	Return linked to WEB-82	RET-17, item SKU-6, quantity one
Refund submitted once	RF-82 against PAY-82	Till records RF-82; no second payout
Stock checked	Return status synchronised if supported	Condition checked before one stock adjustment
Accounts reconciled	One sales credit export	Credit mapped to original sale and refund

Original ASBG swimlane table. It illustrates references, not a tested integration or vendor screen.

Read the table horizontally as well as vertically. Every money movement has one owner, and each mirrored record points to the same event. If an integration does not carry the shared IDs, preserve them in the permitted reference fields or a controlled reconciliation log.

Establish what synchronises automatically

Inspect the integration settings and current provider documentation. Does a web refund create a till return? Does a store stock adjustment update the website? Does the accounting connection import a credit, a refund payment or both? “Connected” is not an answer to those separate questions.

For an unsupported combination, ask the provider or implementer for a documented workflow before experimenting with a live refund. A small controlled test belongs in the POS trial checklist, with the observed result retained rather than assumed.

Check the physical item separately

Record the item, quantity, condition and receiving location. A damaged return should not silently increase saleable stock. If the original platform already restocked it, correct that specific movement rather than adding another return in the second system.

Keep the customer's refund decision separate from stock condition and integration convenience. The consumer-guarantees guide covers remedies, and the ACCC guidance is the primary source for rights that a store policy cannot remove.

Reconcile the refund and close both records

Confirm the provider's final refund status, match the deduction in the settlement and check that only one accounting credit exists. Keep a dated exception if one system has not updated. Send the customer the available refund receipt without promising a bank arrival time you cannot verify.

Use the duplicate-charge checklist for disputed payment counts and the fee audit for costs retained after a refund. The payments hub connects those investigations with the acceptance guides.

Key takeaways

• Assign one system to issue the refund.
• Link money, stock and accounting events through shared references.
• Verify the integration's actual behaviour before correcting both sides.

Where to get help

• Square: returns across locations and unlinked refunds
• ACCC: repairs, replacements and refunds