Skip to end of metadata
Go to start of metadata

Use cases

A change to a person's order will involve the cancellation of an item ordered, requesting a refund or applying the amount as a credit toward alternative items.  The cancellation of an entire order/invoice will involve cancelling all the items in the order and crediting (if unpaid) or refunding the balance.  The financial accounts that are impacted by a change/reversal/refund are determined by the item/s involved (e.g. an event registration, donation, membership, etc).

Part of good bookkeeping practice is to not edit or delete a transaction document (order/invoice/receipt) once it has been sent to the client.  The following use cases assume that this best practice approach will be taken to changes/reversals/refunds.

The use cases can be summarised as follows:

  • Cancellation of one or more items in an order before payment received
  • Cancellation of an item after all/part payment received (with/without cancellation fee) - refund required
  • Addition of items when cancelling others (e.g. cancel a non-member ticket and select a price set with a membership and member priced ticket) - credit adjustment/refund or order/invoice/additional payment required
  • Refund through payment processor also may or may not reverse fees or incur a fee

Cancellation of one or more items in an order before payment received

  1. The user looks up a user and goes to their Contribution tab.  The top section of the Contribution tab could list the Unpaid Orders which are Orders that are unpaid or part paid.
  2. Each Order could also have a little arrow or + next to it that when clicked, expands to show the items within that Order.
  3. The Order should have a new option to Edit, which the user clicks
  4. The Edit Order screen should list the items in the order, with each line preceded with the number of items in the order, so the user can reduce the quantity of an item (in future the user may be able to increase the quantity of an item, with any increase in the quantity requiring a check of availability of the item on submission and collection of the relevant information for the additional quantity, such as participant names)
  5. At this stage there is no ability to add new items
  6. The user submits the order and is prompted with a screen listing what is being cancelled and asking them to confirm.
  7. On confirmation, an invoice with a negative quantity and financial amount is generated/issued, or a credit adjustment is issued listing the credit/s.

Cancellation of an item after all/part payment received


Addition of items when cancelling others


Refund through payment processor also may or may not reverse fees or incur a fee

Data structure

Cancellation of one or more items in an order before payment received

Cancellation of an item after all/part payment received

Addition of items when cancelling others

Refund through payment processor also may or may not reverse fees or incur a fee

Previous examples

Administrative personnel need to be able to change and reverse Event, Membership and Contribution transactions so that accounting requirements for an auditable trail of the changes is kept. Any difference in the transaction balance should be able to be billed or refunded easily within CiviCRM via its payment and refund mechanisms. See [Changing and Cancelling Financial Transactions|]


This scope assumes using the new contribution = obligation model. Payments and refunds are recorded in the financial_trxn table. Foundation work for this is covered in the sizing for Partial Payments below.

Phase 1: Issue a refund of $xx amount against an existing contribution (payment).

The user selects a "Refund" action for paid membership, event registration or contribution record. Goes to a form where they can enter amount to be refunded, confirm date and add refund reason. Option to send refund notification email. This phase does not include modifying event fee or line item selections. If this is needed, user enters a full refund + new registration.
There are two parts to the accounting for this. First is the creation of credit adjustment transaction(s) that records a negative amount against the account for each item being reversed. When the invoice is reissued, there will be a link between the refund and the item being refunded. This will be represented in the db by new records in the civicrm_invoice_line_item and civicrm_invoice_line_sub_item tables with the same account code as the original with a negative amount. The original records will have a link created to the reversing record, as well as to a credit adjustment record that collects all changes made at one time and records a reason for them. The second part of the accounting is the creation of a financial transaction representing the money transfer back to the contact. This action records a negative financial trxn linked to the existing invoice record (or its line items or line sub items if the refund/reversal is for particular item(s) on the invoice.
Processor interaction for refund is optional for payments made via processors that support refunds. Some processors may NOT support partial refunds (needs investigation). For checks or other "manually recorded" payments, we still create the "refund contribution" record.
Completed contributions (donations or contribution payments for memberships, events) can no longer be cancelled in place. Users will need to use the "Refund" action.
50 hrs

Phase 2: Linking refunds to specific line-items.

A refund needs to generate reversal G/L entries at the line item level. Also, support is needed for charging a cancellation fee, which is like a line item.This phase pretty much collapses into the next item below as a result.

Change existing registration fees / selections

The principal requirement in this area is to support changes to event registrations and membership purchases. Registration changes in particular are frequent and need to have an easy to use UX. From a user perspective, they are able to 'edit' an existing invoice transaction. Internally, if there are changes at the time of save, create a new registration/purchase, mark the original as superceded, and record the refund/additional amount in a new difference_amount field.
Issue: how do backoffice staff do an additional payment in case of non-present credit card? Answer: RNAO accept any of a variety of methods of payment for any obligation, including cash, cheques, credit cards, special RNAO credits in accounting system (treated like any other G/L account), etc. They would likely do a PoS terminal credit card transaction if they are getting the credit card over the phone, though it might be nice to do it online via CiviCRM if that is legit.
JM Jan 6, 2011: Additional note: to be more explicit, the changes to existing fees need to be tracked at the line item level, so that if there is a cancellation of one and an addition of another, that needs to be tracked as two separate line item G/L entries.


Support needs to be added for refund and void transactions to the code interacting with payment processors. A separate permission will be created for this. Each plug-in will need to implement this functionality.

Estimate: 100 hrs rough est

  • None
  1. Mar 04, 2013

    What is the update of this issue. Is this available in CiviCRM 4.2? 

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.