Customer credits and refunds

Sooner or later, every business has to give money back. Maybe a part came in damaged, a service didn't go as planned, or you over-billed by mistake. Suprata gives you two tools for this — credits and refunds — and they solve different problems. Picking the right one matters: credits keep the money in the customer relationship and on your books; refunds send cash back out the door and shrink the period's revenue.

This article covers when to use each, how to apply credits to invoices, and what flows to QuickBooks.

When you'd use this

• A returned product. The customer brings back a part; you owe them either a credit toward a future purchase or cash back.
• A service issue. The job didn't go right; you're discounting or refunding the work.
• An over-charge. A pricing error or duplicate invoice was paid; you owe the difference back.
• A goodwill gesture. No specific transaction error, but you're making a customer whole on something — usually with a credit, sometimes a refund.
• A dispute resolution. You and the customer have agreed on a partial credit or refund as the settlement of a billing disagreement.

Credits vs. refunds — the strategic choice

The mechanical difference is simple: a credit is a balance held against the customer's account that gets applied to a future invoice; a refund is an actual return of money to the original payment method (or check, if it was paid by check).

The strategic difference is more interesting:

Default to credit when the customer is staying. It keeps the customer engaged ("I have $200 with them, I should use it") and avoids the friction of issuing a refund and re-charging next time.

Default to refund when the customer is leaving, when they explicitly ask for cash back, or when the credit would be too large to reasonably consume. A $50 credit is fine; a $5,000 credit on a customer who only buys $200/year of services is just deferred refund pressure.

How credits work

A credit in Suprata is a positive balance owed to the customer, attached to their account. It can come into existence two ways:

1. A credit memo issued directly — you create a credit on the customer's account for a stated amount and reason.
2. An overpayment — the customer paid more than the invoice owed, and the excess becomes an account credit automatically.

Once a credit exists, it sits on the account as available balance. It applies to future invoices either:

• Automatically at the time a new invoice is generated (the system can be set to auto-apply available credits to new charges), or
• Manually when you choose to apply it to a specific invoice (most common for one-time credits where you want control over which invoice it lands on).

The Bob Jim sample account shows the customer-record structure where credits live, including the Invoices tab, Payments tab, and Saved Payments tab:

Issuing a credit memo — typical flow

1. Open the customer's account.
2. Find the credits area (often grouped with payments).
3. Add a new credit with:
   • Amount — positive dollar value.
   • Date — usually today.
   • Reason / description — be specific. "Goodwill credit for damaged part on invoice #1234" is a useful audit trail; "credit" is not.
   • Credit type if your system uses categories (e.g., Returns, Goodwill, Adjustment).
4. Save. The credit is now sitting on the account as available balance.

The credit doesn't do anything yet. It sits as a liability waiting to be applied. The customer's next invoice can pull from it; you can also apply it manually to an existing open invoice.

Applying a credit to an invoice

To apply an existing credit to an open invoice:

1. Open the invoice.
2. Find the payment / credit application controls.
3. Apply credit, choosing how much of the available credit to apply (you can apply less than the full credit if the invoice is smaller than the available balance).
4. Save. The invoice's balance due drops by the applied amount; the credit balance drops by the same amount.

If the credit is larger than the invoice, the invoice goes to zero and the remaining credit stays on the account for next time. If the credit is smaller than the invoice, the invoice's remaining balance is still owed.

Once a credit is fully applied, the credit record stays in the account history (you can see when and where it was applied) but no longer has a usable balance.

Issuing a refund — true cash back

A refund returns money to the customer's original payment method. The flow is different from credits because real money is moving:

1. Open the invoice that was paid.
2. Find the payment row (the actual payment that the refund will reverse against).
3. Refund the payment, either fully or partially:
   • Full refund. Reverses the entire payment; the invoice's balance goes back to what was owed before.
   • Partial refund. Reverses some of the payment; the rest stays applied.
4. The payment processor (Stripe, USIO) handles the actual money movement — the refund hits the customer's card or bank in 3–10 business days depending on processor and method.

For payment-processor specifics — what fees come back, settlement timelines, partial-refund rules — see Refunds and partial refunds in the Payments section.

For paid-by-check or paid-by-cash invoices, refunds are a manual operation: you record the refund in Suprata for accounting purposes, and you actually mail a check or hand over cash separately. The system records the refund event but obviously can't move the money for you.

When the original payment is too old to refund

Most processors have a refund window — typically 90 to 180 days after the original charge. After that window, the processor won't let you reverse the original charge directly; you'd have to send a separate payment to the customer (a check, an ACH push, or a new charge of negative amount, depending on processor capabilities).

In those cases, the cleaner workflow is:

1. Issue a credit memo on the customer's account for the amount you owe.
2. Apply that credit to a near-future invoice, OR
3. If the customer wants cash, mail a check from your business bank account and record the disbursement in your accounting system (not as a Suprata refund — those map to processor refunds and won't apply to a check sent outside the system).

What syncs to QuickBooks

If QuickBooks is connected, credits and refunds sync — but they sync as different QB objects:

• Account credit → QB Credit Memo (or sometimes a Journal Entry, depending on setup).
• Refund of a payment → QB Refund Receipt (or it reverses the original payment, depending on configuration).
• Applying a credit to an invoice → QB sees the invoice paid down by the credit memo amount.

A common point of confusion: an account credit followed by an invoice it applies to creates two events in QuickBooks (the credit memo, then the application of that credit to the invoice). If you only see one in QB, that's normal — the second one may show up as a journal entry or a payment receipt depending on how you configured the sync. Check the QB sync log to confirm both events landed.

Common mistakes

• Refunding when a credit would do. If the customer is going to keep buying from you, a credit is operationally simpler — no money movement, no processor fees on the refund, no return-of-funds delay. Default to credit unless they ask for refund.
• Crediting when a refund is what's right. A customer who's clearly leaving doesn't want a credit they'll never use. Refund and let them go cleanly. Trying to "save" the relationship with a credit they won't use just postpones the awkwardness and clogs your books with stale credits.
• Not documenting the reason. "Credit $50" with no description is the kind of entry that becomes incomprehensible at audit. Always note the reason and reference the underlying invoice/job.
• Applying credits manually when auto-apply is on. If you've enabled automatic credit application on new invoices, manually applying a credit at the same time can apply twice. Pick one mechanism and stick with it.
• Refunding a partially-paid invoice without considering what's left. Refund $50 of a $100 invoice that had been paid in full, and the invoice now shows $50 owed (correctly!). If you didn't intend that, you needed a credit, not a refund.
• Expecting QuickBooks to update instantly. Issue a refund in Suprata; check QB a few minutes later and don't see it; panic. The QB sync runs on a delay (usually within an hour). Give it time before assuming something's broken, then check the QB sync log if it still hasn't landed.
• Issuing refunds for amounts larger than the original payment. Some processors allow this, some don't. Most don't, on policy. The clean fix is to refund up to the original payment, and issue the rest as a separate payment from your bank account or a credit on the account.

Related articles

• Estimates vs. invoices
• Sending an invoice to a customer
• Closing, voiding, and reactivating invoices
• Refunds and partial refunds
• Handling a customer dispute
• QuickBooks prerequisites