> ## Documentation Index
> Fetch the complete documentation index at: https://orgo.space/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Cancelling & Correcting Invoices

> Void an invoice raised in error, handle duplicates, and correct a test registration

Invoices get raised in error. Someone books twice because the first confirmation
never arrived, an administrator creates a test registration to check the payment
flow, or a member is invoiced on the wrong plan.

The action you want is almost always **void**, not delete.

***

## Voiding an invoice

**Invoices**, open the invoice, then **Void**.

Voiding does two things. The invoice moves to a voided state, and the payment
record attached to it is cancelled, so the amount stops counting toward what the
member owes and stops appearing in financial totals.

<Note>
  Voiding keeps the invoice in the record. That is the point. An invoice that
  vanishes leaves an unexplained gap in your numbering and no answer to the
  question "what happened to invoice 214?". A voided invoice answers it.
</Note>

***

## Duplicate bookings

When someone registers twice, void the duplicate rather than removing the person.

<Steps>
  <Step title="Identify which one to keep">
    Keep the invoice the member has already paid or already sent to their finance
    department. Ask if you are unsure, because the reference number they quoted
    internally is the one that must survive.
  </Step>

  <Step title="Void the other">
    The cancelled payment record stops the duplicate counting toward revenue.
  </Step>

  <Step title="Remove the duplicate attendance">
    Voiding the invoice does not by itself remove the second registration from the
    attendee list. Remove the duplicate attendee separately so check-in and
    attendee reports are correct.
  </Step>
</Steps>

***

## Test registrations

If you create a test registration to check a payment flow, void its invoice and
remove the attendance afterwards. Test rows left in place inflate attendee counts
and revenue totals, and they are hard to spot later because they look exactly
like real ones.

<Warning>
  Do not use a real member's account to test a payment flow. If you later mark that
  invoice paid while tidying up, the member is emailed a paid invoice for something
  they never bought.
</Warning>

***

## When money actually changed hands

Voiding is for an invoice that should not have existed. **Voiding does not return
any money.** If a member has genuinely paid and needs it back, that is a refund,
which is a separate operation: **Fees** → **Payments**, open the payment, then
**Refund**, for the full amount or part of it.

The money returns to the card or account it came from. Note that the payment
processor's own fee is not returned, so a refunded transaction still costs your
organisation that fee.

<Warning>
  Do not void a paid invoice expecting the member to be refunded. The invoice will
  show as cancelled while the money stays where it is, and nobody will notice until
  the member asks.
</Warning>

***

## Related

* [Recording a payment](/docs/platform/fees/record-payment) — marking an invoice paid
* [VAT & Invoice Templates](/docs/platform/fees/vat) — tax details on the document