A customer complains about an incomplete service, and the manager agrees to a partial refund by email. Customer service marks the complaint as resolved. The customer expects payment, but finance never receives the approval and the original sale remains unchanged in the accounts.
Weeks later, the customer follows up. Another employee forwards the request, a payment is arranged urgently, and the refund appears in a different reporting period from the decision that created it. What began as a straightforward service response has become an accounting discrepancy and an avoidable customer frustration.
Lee & Hew provides accounting, bookkeeping and financial reporting support. For businesses managing refunds across several teams, reliable records depend on connecting the commercial decision with the accounting and payment process. An approval should begin a traceable sequence, with a clear record of what remains outstanding until the matter is settled.
Identify Where the Handover Breaks Down
Refund requests often begin outside finance. They arrive through customer service inboxes, sales messages, online platforms or conversations with an account manager. The person handling the complaint may believe their responsibility ends once a manager approves the request.
Finance may operate on a different assumption. It expects an approved form, a credit note request or an entry in a payment system. When nobody completes that step, the approval remains in an email thread that does not appear in the month-end records.
Map the actual process before introducing another form or software tool. Establish who receives the request, who makes the decision, who records the accounting effect and who releases payment. Identify what information passes between those people.
The gap is often an undefined responsibility. Forwarding an email to a shared mailbox does not establish that someone has accepted the task or completed it.
Distinguish a Request From an Agreed Refund
Not every customer request is an approved payment. Some require investigation, while others depend on returning goods, confirming a service failure or agreeing a settlement amount.
Record the status precisely. “Under review”, “approved subject to return”, “approved for payment” and “payment completed” describe different positions. A single label such as “resolved” can hide whether the customer has received anything or whether conditions remain outstanding.
Retain the approval and its terms. Finance should be able to identify the amount, reason, approving person and any conditions without interpreting a long conversation. Changes to an earlier decision should be documented as well.
These distinctions also support accounting review. Management needs to assess the underlying facts and obligations, rather than treat the existence or absence of an internal approval flag as the only basis for recognition.
Connect the Refund to the Original Transaction
Each refund should link to the customer, original invoice or order, and the payment already received. Without that connection, finance may be unable to determine whether the business owes cash, should reduce an unpaid invoice or needs to correct a duplicate receipt.
A customer who has not paid an invoice generally presents a different settlement situation from one who has paid in full. Reducing an outstanding charge is not automatically a cash refund. Paying money without checking the original receipt can create an unnecessary loss.
Partial payments require particular care. Confirm the amount received, the amount still due and the agreed adjustment before determining the settlement. Do not assume the invoice total represents cash held.
Use a unique refund reference that remains consistent across customer service, accounting and payment records. This allows the teams to follow one case through to completion.
Assess the Accounting Effect Before Cash Leaves
Where the business expects to return consideration it is not entitled to retain, revenue guidance may require a refund liability and an adjustment to the amount of revenue recognised. Waiting for the bank payment can leave the reporting incomplete.
The original accounting matters. Returning a customer advance for an undelivered service may reduce an existing liability rather than reverse revenue. Refunding a duplicate payment also differs from granting a price concession on a completed sale.
Finance should therefore identify the reason for the refund and review how the original transaction was recorded. Applying one standard expense code to every outgoing refund can distort both revenue and costs.
The assessment should also consider existing refund estimates or allowances. An individually approved refund may already be included in a broader recorded amount, so the company must avoid recognising the same exposure twice.
A Month-End Example Shows the Timing Problem
Consider a hypothetical service company that collected S$12,000 and recognised the related revenue. Before month-end, it agrees an unconditional S$3,000 reduction because part of the service was not delivered as agreed. The customer receives written confirmation, but finance is not informed until the following month.
Assume the assessment supports reducing the recognised revenue and recording a refund liability, with no existing allowance covering the amount. The month-end accounts should reflect that position even though the cash payment has not yet been processed.
When the S$3,000 is subsequently paid, the payment settles the recorded liability. Recording a new expense at that point, without checking the earlier adjustment, could duplicate the effect.
This example excludes tax and illustrates the need for a complete handover. Different facts, including a customer advance or a refund already reflected in an estimate, would require a different entry. The payment date alone cannot determine the treatment.
Create a Refund Register With Separate Milestones
A refund register can provide a shared view of the process without requiring every department to use the same operational system. Include the original transaction, request date, approved amount, conditions, accounting reference and payment status.
Track accounting completion separately from payment completion. A refund can be properly recorded but still unpaid. It can also be paid through an online platform while the accounting adjustment remains outstanding.
Record the expected payment date and any reason for delay. Missing customer information, a failed transfer and an internal processing backlog require different actions. A useful register makes that distinction visible.
Restrict access appropriately, particularly where payment details or personal information are included. The shared record should provide the information staff need without exposing unnecessary customer data.
A Credit Note Is Not Proof of Payment
Issuing a credit note can document an adjustment to a customer’s charge, but it does not establish that cash has been returned. Customer service should not tell the customer that payment is complete solely because a credit note exists.
Similarly, a credit balance on a customer account needs explanation. It might represent an unpaid refund, an amount agreed for future use or an unmatched payment. These outcomes should not remain indistinguishable in the ledger.
Where the customer accepts account credit instead of cash, document that agreement and the relevant conditions. Do not substitute store credit for an agreed cash refund simply because it is easier for the business to process.
Link subsequent use of the credit to the original case. Otherwise, the company may apply a discount to a new sale while retaining the old credit, allowing the same concession to be used twice.
Reconcile Payment Platforms and Bank Settlements
Refunds processed through a card provider or marketplace may appear as deductions from later settlements. Finance could therefore receive less cash without seeing a separate refund payment in the bank account.
Obtain the platform’s transaction detail and match refunds to the relevant orders. Reconcile gross collections, refunds, fees and other adjustments to the amount deposited. Recording only the net bank receipt may conceal why the settlement changed.
Keep chargebacks separate from voluntary refunds until their status is understood. If a customer has already recovered money through a chargeback, issuing another refund could create a duplicate payment. Check the latest platform information before release.
A failed or reversed refund also needs follow-up. A system status indicating that a request was submitted is not necessarily evidence that the customer received the money. Retain confirmation of the actual outcome.
Coordinate Goods Returns Without Assuming Everything Is Resolved
Where a refund involves returned goods, the physical and financial processes need to connect. Record whether the goods have been received, their condition and the decision about resale, repair or disposal.
Do not assume that a refund automatically returns usable stock to the business. The customer may be permitted to retain the item, the goods may be damaged or the return may still be in transit. Inventory records require their own supported assessment.
Where approval depends on a return, customer service and finance should understand the condition and receive the relevant confirmation. Any decision to waive that condition should be authorised and recorded.
Keeping the processes linked helps explain the total effect of the case. The business may face a revenue adjustment, delivery expenditure and a loss on the returned item, rather than a single outgoing payment.
Review Outstanding Refunds Before Closing the Period
Month-end procedures should include approved and unresolved refund cases, not only payments already visible in the bank. Ask relevant teams to confirm whether decisions remain in emails, platform messages or local spreadsheets.
Reconcile the refund register to credit balances and recorded liabilities. Investigate differences, including cases marked as paid operationally but still open in finance. Check whether a payment has been posted to the wrong customer or account.
Review significant requests still under assessment. Their treatment depends on the facts and applicable requirements; lack of formal approval does not automatically mean there is nothing to consider. Equally, a complaint alone does not establish that the requested amount is payable.
Keep relevant later developments available during the reporting process. The appropriate period and treatment should be assessed rather than determined solely by when someone finally forwards the email.
Separate Authorisation From Payment Release
The person approving a commercial settlement should have authority appropriate to its amount and nature. Payment release should then follow the company’s controls, including verification of the beneficiary and checks against earlier refunds.
An urgent customer complaint should not remove those checks. Pressure to resolve a delay can make staff more likely to overlook a payment already processed by another team.
Where practicable, use review by another person for significant refunds. Smaller businesses can apply a proportionate process, but someone should still verify the original transaction, approval and payment history.
Keep an exception record when the normal process cannot be followed. The reason, authorisation and later review should remain visible rather than allowing urgent cases to become undocumented transactions.
Use Refund Information to Understand Performance
A complete refund record provides more than an accurate payable balance. It can show recurring problems with particular services, products or stages of fulfilment.
Separate reasons meaningfully. A cancelled booking, duplicate payment, pricing error and service complaint point to different issues. Combining them under “refund expense” makes it difficult for management to decide what to improve.
Review amounts alongside the related sales activity. A larger refund total may reflect higher sales volume, while repeated concessions on one service may indicate a pricing or delivery problem. The explanation matters more than the total alone.
Lee & Hew’s accounting and financial reporting support helps connect these records with management information. The business can then review both the outstanding obligations and the operational causes behind them.
Give Every Open Case an Owner
A customer should not have to restart the process each time they follow up. Assign responsibility for taking an approved refund through the remaining steps, even where several teams contribute.
The owner should confirm that finance has received the information, payment has been scheduled and the outcome has been communicated. They do not need authority to perform every step, but they need a clear route for escalating delays.
Review aged cases regularly. Focus on why they remain open and what action will resolve them. A repeated note saying “awaiting finance” is not sufficient where nobody has established what finance is waiting for.
ACRA’s financial reporting guidance emphasises management processes that support complete and accurate records, with directors retaining responsibility for the statements. A clear refund handover is one practical part of that wider responsibility.
Close the Case in Both Customer Service and the Accounts
A refund is not complete merely because it was approved, a credit note was issued or a payment request was submitted. The final status should reflect the agreed outcome, the accounting treatment and evidence of settlement.
Review the process from the customer’s original request through to the ledger and payment record. Resolve duplicate entries, retain supporting documents and make remaining obligations visible. This helps the business avoid both understated refunds and unnecessary repeat payments.
Speak with Lee & Hew through Audit Services Singapore about its accounting, bookkeeping and financial reporting support. A consistent refund process helps ensure that commitments made to customers reach the accounts and are followed through to resolution.