Credit Requests and Disputes
Money coming back to a customer is a two-person job. Somebody who is talking to the customer raises the request; somebody who holds the billing permission approves it and posts it. This page covers both halves, plus the billing dispute that often starts the conversation.
The three kinds of request
Section titled “The three kinds of request”| Type | What it is |
|---|---|
| Refund | Giving back a specific charge, in whole or for part of a period. Raised from that charge |
| Credit | Correcting the account by an amount |
| Goodwill Gesture | A discretionary amount, recorded as its own transaction type so goodwill spend is visible in reporting |
Raising a request
Section titled “Raising a request”Request Credit on the customer’s Invoices tab raises a credit or goodwill gesture. Request Refund on a charge’s record page raises a refund, with the type and the charge already filled in.
Required for every request: the Request Type, a Reason from your configured list, and Details - the explanation the approver will read: what happened, and how you arrived at the amount.
Optional: the Case this request settles, where there is one, such as a billing dispute.
For a refund: the charge being refunded, and optionally Refund From and Refund To dates to refund part of a period. A refund carries no amount; it is computed from the charge.
For a credit or goodwill gesture: the Amount to credit, before VAT. These never cite a charge.
The rules the form enforces:
- A refund must cite a charge - it is raised from the charge being refunded.
- That charge must belong to this customer, must be billed (unbilled charges are corrected by editing or deleting them), must carry a value, and must not already be fully refunded.
- Only one pending request per charge.
- A credit or goodwill gesture must carry a positive amount and must not cite a charge.
- A linked case must belong to the same customer.
You can still Edit Request while it is pending.
Approving
Section titled “Approving”Credit Requests in the Billing menu is the queue.
Pending lists the outstanding requests with when they were raised, the customer, the type, the amount, the reason and who raised it. Decided shows the history with the outcome and who decided it.
A refund whose amount has not been computed yet shows From charge rather than a figure.
What you need to decide: the backend Transactions Add permission. There is deliberately no separate approve permission - the ability to post a transaction is the ability to approve one.
Each pending row carries a Decision note box and Approve and Reject buttons. A rejection note is required; an approval note is optional.
Somebody who raised a request but cannot decide it gets Cancel Request instead. Anyone without either sees the queue read-only, with a note explaining what approving needs.
The credit ceiling
Section titled “The credit ceiling”Every approver has a maximum credit value. It is checked after the money is computed, inside the posting, so an over-limit approval rolls back entirely rather than half-posting.
For a credit or goodwill gesture you see This amount is above your credit limit. For a refund you see the computed figure, for example The computed refund of 42.50 is above your credit limit, because the amount is only known once the refund has been worked out.
What approval posts
Section titled “What approval posts”- A refund produces a genuine refund line citing the charge it refunds.
- A credit or goodwill gesture posts as a credit line on the customer’s next chargeable invoice, described by the reason you chose, with an anchor against their oldest outstanding invoice so it reduces the debt being chased straight away.
Approved credits always post to the next bill. Turning them into an actual credit-note document is a separate step.
Other refusals you may meet
Section titled “Other refusals you may meet”- This request has already been decided
- The charge this refund cited no longer exists - cancel the request
- The cited charge does not belong to this customer
- The cited charge is not on a sent, approved invoice - correct it there instead
- The refund could not be raised (the charge may already be refunded for that period)
- The customer has no open invoice to credit - create their next invoice first
Important: requests are cancelled, never deleted. The record is the audit trail of what was asked for and what was decided.
Raise Credit Note
Section titled “Raise Credit Note”Raise Credit Note on the customer’s Invoices tab bundles the pending refund and credit lines into one credit-note invoice and produces it immediately.
Optional: raised on behalf of, a reason and details.
What you need: the credit notes module, permission to add invoices, and the same credit ceiling.
The same action is available on the customer’s Actions menu in the billing backend.
Billing disputes
Section titled “Billing disputes”A dispute is recorded on a case, because a dispute is a conversation.
Record Dispute
Section titled “Record Dispute”Required: What is in dispute.
Optional: the Invoice in dispute (or “No specific invoice” for an account-level disagreement), and the Amount in dispute where you know it. Leave the amount blank if the whole invoice is contested.
What happens: where the cited invoice has an open chase item, a hold is placed on that invoice only, blocking contact, charges and restriction, with the case named as the reason. Any scheduled or queued chase correspondence for it is cancelled, and the invoice is kept out of chase auto-enrolment while the dispute is open.
Important: the rest of the customer’s debt keeps being chased. Disputing one invoice does not stop everything.
Important: only one open dispute per case, and the cited invoice must be one of that customer’s raised invoices.
Resolve Dispute
Section titled “Resolve Dispute”Required: the Outcome - Credit / refund agreed or Charge upheld - and a staff-only resolution note.
What happens: the holds that dispute placed are released. A hold Credit Control added by hand, or one from another dispute, is left alone.
Where a credit or refund was agreed, the case offers Raise Credit Request so the money side follows straight on.
Field reference
Section titled “Field reference”Request
Section titled “Request”What is being asked for: the type, the transaction being refunded where applicable, the amount and the reason.
| Field | Description |
|---|---|
| Customer | The customer the credit or refund is for |
| Case | The case (for example a billing dispute) this request settles, where there is one |
| Request Type | What is being asked for: a Refund of a specific charge, a Credit correcting the account, or a Goodwill Gesture |
| Transaction To Refund | For a Refund request: the billed transaction being refunded (raise the request from that charge's record page) |
| Refund From | For a partial refund of a period charge: the first day to refund (leave blank to refund the whole charge) |
| Refund To | For a partial refund of a period charge: the last day to refund (leave blank to refund the whole charge) |
| Amount | For a Credit or Goodwill Gesture: the amount to credit, before VAT (a Refund's amount is computed from the charge being refunded) |
| Reason | Why the credit or refund is being asked for |
| Details | The explanation the approver will read: what happened, and how the amount was arrived at |
Decision
Section titled “Decision”The lifecycle of the request: who raised it, the decision, and the posted transaction.
| Field | Description |
|---|---|
| Status | Where the request is in its lifecycle |
| Requested By | The operator who raised the request |
| Requested | |
| Decided By | The billing-permission holder who approved or rejected the request |
| Decided | |
| Decision Notes | The approver's note on the decision |
| Posted Transaction | The transaction the approval posted |
System Information
Section titled “System Information”| Field | Description |
|---|---|
| Last Modified | Timestamp of the most recent modification to this credit request |
| Created | Timestamp when this credit request was created |