Returns are a normal part of any operation that handles physical goods. Damaged, defective, wrong specification, or simply unneeded inventory gets shipped back to vendors under a Return Merchandise Authorization process.
From the supplier side, the return triggers a credit note. From the buyer side, the credit should arrive in AP and get posted against the original invoice. The handoff between physical receiving and financial posting is where the breakdown happens.
When the handoff fails, the inventory leaves the building, the credit never arrives, and the original invoice gets paid in full. The financial impact accumulates quietly.
The Standard Returns Workflow
A clean returns workflow has six steps. Each step has an owner and produces a record that the next step depends on.
- Receiving or operations identifies goods to be returned: damaged, defective, wrong specification, or excess inventory.
- The buyer requests an RMA from the vendor. The vendor issues the RMA with authorization, return instructions, and the expected credit amount.
- The goods are physically returned, with the RMA number referenced on the shipping documentation. Tracking is retained as proof of return.
- The vendor receives the returned goods, inspects them, and confirms the return.
- The vendor issues a credit note referencing the original invoice and the RMA.
- AP receives the credit note, validates it against the RMA and the original invoice, and posts it.
Each step depends on the prior step producing the right record. If any step does not communicate forward, the credit chain breaks.
Where the Workflow Breaks Down
Five failure points account for most missing returns credits.
Returns processed informally without RMA
The receiving team identifies damaged goods and arranges return directly with the vendor's local rep without going through the formal RMA process. The return happens, but there is no documented expectation of a credit. The vendor may or may not issue one.
RMA issued but not communicated to AP
Operations gets the RMA from the vendor, the goods ship back, and the matter is treated as closed from the operations perspective. AP is never notified that a credit is expected. When the credit arrives weeks later, AP has no context for what it represents.
Original invoice paid before credit arrives
The invoice payment cycle runs on its standard schedule. The credit arrives after payment has cleared. AP now has a vendor credit in the account but the original invoice is already settled. The credit sits unapplied unless someone monitors the account.
Partial credits and restocking fees
The vendor accepts the return but issues a partial credit after deducting a restocking fee or other adjustment. AP may post the credit as if it were full and miss the discrepancy, or may dispute the partial credit without understanding it was contractually expected.
Vendor fails to issue the credit at all
The return happens, the RMA is documented, but no credit ever materializes. Without active follow up from AP or operations, the matter quietly closes without recovery.
The Receiving and AP Integration
The structural fix is to integrate the returns workflow with AP, so that every RMA generates a tracked expectation in the AP system.
RMA registration in the AP system
When operations receives an RMA from a vendor, a corresponding record gets created in AP showing the expected credit, the original invoice it relates to, and the expected timing. The record functions like an open invoice in reverse, an open expected credit.
Hold on the original invoice if not yet paid
If the original invoice is still in the payment pipeline when the RMA is issued, the invoice can be held until the credit is received and applied. This avoids the awkward situation where the invoice pays in full and the credit then sits unapplied.
Follow up triggers if the credit does not arrive
Each open expected credit has a target receipt date based on the RMA terms. If the date passes without the credit arriving, an automatic follow up flags it for AP action. This is the discipline that prevents vendors from quietly failing to issue credits.
Restocking Fees and Partial Credits
Many vendor contracts allow for restocking fees on returned goods, typically 10% to 25% of the returned value depending on the category and the circumstances of the return.
When restocking fees apply, the credit is for less than the original invoice amount. AP needs to know what the expected credit amount is to validate it when it arrives. Without that expectation, two errors are common.
The first error: posting the partial credit as if it were the full expected amount, which leaves an open balance that should have been recognized as a restocking fee expense.
The second error: disputing the partial credit because it does not match the original invoice amount, when in fact the restocking fee is contractually appropriate.
The RMA registration record should include the expected credit amount net of any restocking fees, so the credit posts correctly when it arrives.
Tracking Outstanding RMAs
An outstanding RMA register, maintained by AP with input from operations, is the most direct way to ensure returns credits do not go missing. The register includes:
- Vendor and original invoice number
- RMA number and issue date
- Expected credit amount, net of any restocking fees
- Expected credit receipt date
- Status: pending shipment, in transit, received by vendor, credit issued, credit applied, closed
Reviewed weekly or biweekly, the register surfaces RMAs that are not progressing on schedule and need follow up. Vendors that consistently delay or fail to issue credits become flagged for procurement attention as a relationship quality issue.
Start Here
Talk to operations or receiving and ask how returns are currently tracked. If the answer is informal or inconsistent, that is the gap. The first step is documenting the current process before changing it, because the current process usually varies more by individual than most finance leaders realize.
Once documented, the AP integration is the highest leverage change. An RMA register linked to the AP system, with target receipt dates and follow up triggers, converts an invisible workflow into a tracked one.
