Handle a customer short payment by separating the cash received from the decision about the missing amount. Identify the affected invoice, preserve the customer's explanation and route the difference for acceptance, investigation or approved small-balance treatment. Closing an invoice should follow a documented decision, rather than become the reason for making one.
This guide focuses on short-pay classification and operational ownership. It does not replace your accounting policy, contractual terms or tax advice. The examples are hypothetical and use simple amounts to explain the decision process.
A short payment can arise from an agreed discount, a pricing mistake, a delivery dispute, a bank charge or a customer's unilateral deduction. Those cases may arrive through the same payment screen but require different evidence and approval.
Start with a case record containing the original invoice, amount outstanding before payment, cash received, disputed amount, currency and remittance reference. Record the customer's stated reason separately from your accepted reason. This preserves the difference between a claim and a conclusion.
Ask four questions in order. Does the cash belong to this customer and invoice? Is the difference explained? Has the business accepted the explanation? Which approved transaction treatment records that decision? Stop at the first unsupported answer and assign a specific investigation action.
Oracle's Deduction and Chargeback Management documentation distinguishes accepted deductions, chargebacks that retain an amount for collection, and small-balance write-offs. Its chargeback approach can settle the original trade invoice while leaving a separate chargeback invoice open.
The same documentation explicitly states that the SuiteApp has not been tested with SuiteTax. Treat this as a compatibility review gate. Do not assume that a general NetSuite capability description establishes suitability for a particular tax configuration.
Feature names also need business definitions. A chargeback in this SuiteApp context is not necessarily a payment-card network dispute. Use a reason taxonomy that makes the distinction clear to AR staff, customer service and finance reviewers.
If a valid discount or commercial adjustment is already approved, collect the supporting agreement and follow the configured deduction process. If the customer has claimed a shortage that operations has not confirmed, preserve the claim and route it to the receiving or fulfillment owner.
If the difference appears to be a bank or payment-service fee, compare gross remittance and net settlement evidence. Do not classify every net receipt as a customer refusal to pay. Conversely, do not expense a customer's deduction as a bank fee because that account happens to clear the balance.
If the amount is small, evaluate the approved threshold, reason restrictions and aggregate exposure. Ten individually small differences can represent a recurring pricing problem. Require an exception for repeat patterns or unusual counterparties even where each item falls below the normal approval threshold.
For an unexplained difference, retain it as an open investigation under the controller's approved treatment. Make the next action concrete: obtain delivery evidence, confirm the contract price, request remittance detail or verify the customer's calculation.
AR owns receipt identification and the case timeline. Sales or commercial operations owns negotiated terms. Warehouse or service delivery teams supply fulfillment evidence. Tax and accounting reviewers approve treatment when the issue changes tax, revenue or an accounting period.
The collector should know who can decide the case, what evidence that person needs and when a decision is due. Avoid routing everything to a generic finance queue. A named evidence owner makes it possible to distinguish waiting for a document from waiting for approval.
For each reason code, document the usual decision-maker, permitted transaction path, required attachment and escalation condition. Keep an explicit route for unsupported reasons so users do not select the closest-looking code merely to save a transaction.
A customer owes 8,000 and pays 7,730. Its remittance describes a 200 promotional allowance and a 70 delivery claim. The commercial team confirms the allowance, but the delivery team has not yet verified the shortage.
The case therefore contains two decisions. The accepted 200 follows the approved deduction treatment. The remaining 70 remains collectible or under investigation according to policy. Recording the entire 270 as one approved discount would conceal the unresolved claim.
If the configured SuiteApp chargeback flow is used for the 70, reviewers should follow the resulting chargeback invoice rather than assume that a paid original invoice means all cash has been collected. The example illustrates classification, not a prescribed journal entry or tax result.
Oracle explains that deduction, chargeback and write-off types influence the accounts used through their associated accounting items and setup. Review that mapping with the controller before staff begin choosing reasons.
Test a representative accepted deduction, a contested amount, a mixed case and a small-balance exception. Inspect all generated transactions, subsidiary, currency, classifications and posting periods. Document the intended result before execution so reviewers compare against a business expectation rather than merely accept whatever the system produces.
An approval threshold needs an owner and a review date. Include who may change it, how changes are tested and how the team identifies amounts split across several cases. Small-balance authority should remain visible in the audit trail.
A separate deduction queue should show amount, age, reason, evidence owner and next action. Add the original invoice reference and any replacement transaction so collectors can explain the full history without opening unrelated records.
Track resolution outcomes: accepted commercial adjustment, recovered cash, rejected customer claim, corrected invoice and approved write-off. Measure elapsed time by stage. Long waits for delivery evidence require a different remedy from slow approval of already substantiated claims.
Review repeated deductions by customer and reason. The useful question is whether the underlying cause can be removed, such as an incorrect price list or inconsistent delivery documentation. Do not use a falling open-invoice count as the only success measure; balances can disappear through credits without additional collection.
Before changing a previously handled deduction, inspect the linked payment, credit and chargeback records. Oracle's chargeback processing description explains that the SuiteApp creates related transactions, so a correction needs to consider the chain.
Preserve the original decision evidence and record why it changed. Ask an accountant to validate reversals, period treatment and tax consequences. Where the same issue repeats, CuriousRubik's NetSuite support services can help investigate configuration and process gaps using the actual transaction history.
No. First determine whether the business accepts the difference. An unresolved customer claim and an approved concession have different consequences and should retain separate evidence.
Escalate the pattern even if individual amounts are below a threshold. Review accumulated exposure and its commercial cause before repeatedly writing balances off.
No. Oracle currently states that Deduction and Chargeback Management has not been tested with SuiteTax. Confirm a supported approach for your account before implementation.
A configured chargeback process may move the disputed amount to a separate invoice. Follow the linked records and the open case, rather than looking only at the original invoice status.
AR should coordinate the case, while the team holding delivery evidence verifies the claim. The authorized commercial or accounting approver decides the treatment under your policy.