Answers.Body: <p>With respect to the overpayments, I don't know whether this will fit standard British accounting practices but I'd be inclined to create a separate financial type for the overages - a holding fund, if you will - and record one payment for the membership fee and one for the overage.  They could then add an adjustment transaction the following year to move those funds from the overage account to the subsequent year's membership fee; that would make what happened and why abundantly clear to any auditors who review the financials later.  That would also enable searching/reporting on that financial type.  (I have at least one client that does this when they receive overpayments.)</p>
  
  <p>Regarding underpayment, perhaps the membership could be kept in pending status until the total amount has been collected; those pending members could be added to a smart group that could be used to filter contribution reports to find how much they've paid toward their membership, send email reminders, etc.</p>
  
  <p>That may not get you 100% toward where you want to go but hopefully it's a start.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-24T19:13:50.293Z
Answers.LastActivityDate: 2015-07-24T19:13:50.293Z
Answers.UserDisplayName: Lesley Carter - BackOffice
Answers.Body: <p>The quote from the documentation is perhaps alluding to the fact that you can create a price set where the various options can be allocated to different financial types, but I don't believe it is relevant for your situation where you already have a contribution record for the membership.</p>
  
  <p>I agree with Lesley's suggestion of a separate financial type for overpayments.</p>
  
  <p>If you don't want to keep a membership that is underpaid as pending then my non-code solution for underpayments would be as follows (assumes financial type for membership payments is Member Dues):</p>
  
  <ul>
  <li>Create an "Overdraft" financial type</li>
  <li>Create a new payment instrument of "transfer"</li>
  <li>When a cheque comes in for less than the full amount:
  
  <ul>
  <li>Record the cheque against the pending contribution changing it to completed</li>
  <li>Record contribution for the amount not paid with financial type of "Member Dues" and paid by "transfer" </li>
  <li>Record contribution of -(amount not paid) with financial type of "Overdraft" and paid by "transfer" .</li>
  </ul></li>
  </ul>
  
  <p><a href="https://i.sstatic.net/65C4V.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/65C4V.png" alt="Underpayment"></a></p>
  
  <p>If you like to have every contribution with the financial type of "Member Dues" linked to an actual membership, then you can "renew" the membership to record the additional $10 "payment" then edit the end date appropriately.</p>
  
  <p>It is not exactly a speedy procedure, but does mean that the contribution records reflect the true situation. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-28T15:07:37.407Z
Answers.Text: Many thanks JoAnne. Each contribution may actually cover several items: 2 memberships, donation, fees, recorded with different financial types via price sets. Membership org wants report showing, for each contribution, the membership, donation & fee elements as well as total due, amount received and amount of any over/underpayment. I like the idea of changing the contribution amount from e.g. £100 to £90 when the £90 cheque is received: this allows comparing amount due (from line items) with amount received. Sadly Civi doesn't allow editing the contribution amount through the UI in this case.
Answers.UserDisplayName: davejenx
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-05T12:49:44.290Z
Answers.Text: Although you can't modify the amount of the price set you could still work out how much was actually paid. It will be the the amount "received" for the Dues, plus the amount of the "overdraft" (which will be a negative amount.)  The "total contributions" for an appropriate time interval will give you that amount.
Answers.UserDisplayName: JoAnne
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-25T03:50:16.550Z
Answers.LastActivityDate: 2015-07-25T05:43:22.210Z
Answers.LastEditDate: 2015-07-25T05:43:22.210Z
Answers.UserDisplayName: JoAnne
Body: <p>The type of underpayment or overpayment I have in mind is as follows. An organisation signs up for a membership valued at £100, opting to pay later. So there's a pending pay-later contribution for £100. They send a cheque for £90 or £110. This is not an intentional extra £10 donation or partial payment: they just sent the wrong amount.</p>
  
  <p>The common-sense solution might be to tell the member they sent an incorrect payment and ask for a correct one. Sadly the membership organisation doesn't want to do that, they want to record that an underpayment or overpayment was made and carry this forward.</p>
  
  <p>They also want to be able to report on a set of contributions, seeing the amount due and the amount received.</p>
  
  <p>I know that there have been relevant changes to Civi core as part of the CiviAccounts project, e.g. <a href="http://wiki.civicrm.org/confluence/display/CRM/Phase+1+Implementation+-+Data+Structure+Changes" rel="nofollow">Phase 1 Implementation - Data Structure Changes</a>, aimed at distinguishing 'commitments to pay' from 'payments'. I understand that some parts have been implemented, e.g. <a href="https://issues.civicrm.org/jira/browse/CRM-13964" rel="nofollow">partial payment for events</a>, but others not.</p>
  
  <p>What isn't clear to me is whether or how this infrastructure can be made use of in current Civi 4.6 for the above scenario. Or whether, as things stand, we need to use an alternative approach such as...</p>
  
  <ol>
  <li>Add a custom field on Contribution for Amount Received.</li>
  <li>Add a custom field on Contribution for Amount Over/underpaid.</li>
  <li>Record a separate positive or negative contribution for over or underpayment.</li>
  <li>Suggest that this information is best recorded outside Civi, in an accounts package.</li>
  </ol>
  
  <p>This section of the <a href="http://book.civicrm.org/user/current/contributions/what-you-need-to-know/" rel="nofollow">CiviContribute documentation</a> sounds relevant:</p>
  
  <blockquote>
    <p>For example, a fund raising dinner that charges $100/person may now
    allocate the true costs toward the relevant accounts i.e. $75 donation
    posted to the Income account named "Donations" and the $25 Cost of
    Sales account to "Event Fees".</p>
  </blockquote>
  
  <p>However I'm not clear whether that is the right thing to do in this case or how the person recording the payment would do it.</p>
  
  <p>CiviCRM 4.6, Drupal 7.</p>
  
  <p><em>Edit 31 July 2015:</em> adding relevant details of the use case, which I foolishly omitted to keep things simple...</p>
  
  <p>Each contribution may actually cover several items: 2 memberships, donation, fees, recorded with different financial types via price sets. The membership organisation wants a report showing, for each contribution, the membership, donation &amp; fee elements as well as total due, amount received and amount of any over/underpayment.</p>
  
  <p>I like the idea, in @JoAnne's answer, of changing the contribution amount from e.g. £100 to £90 when the £90 cheque is received: looked like this might allow a custom report to compare amount due (from line items) with amount received. Sadly the contribution edit form doesn't allow changing the contribution amount when the contribution has line items. I tracked this down to <code>templates/CRM/Contribute/Form/Contribution.tpl</code>, line 97:</p>
  
  <pre><code>{if $action eq 2 and $lineItem and !$defaultContribution}
    (...then view total instead of showing edit field...)
  </code></pre>
  
  <p>I assume this was done for good reason: Civi wants to keep the contribution amount consistent with the line items and it wouldn't know which line item to alter. So for underpayment, looks as though the admin would need to record an additional negative contribution for the amount underpaid.</p>
  
Tags: <civicontribute><civireport><accounting>
Title: How to model and report on unintentional underpayment and overpayment?
ThreadText: # How to model and report on unintentional underpayment and overpayment?
  
  (Asked by: username_0 on 2015-07-24)
  
  The type of underpayment or overpayment I have in mind is as follows. An organisation signs up for a membership valued at £100, opting to pay later. So there's a pending pay-later contribution for £100. They send a cheque for £90 or £110. This is not an intentional extra £10 donation or partial payment: they just sent the wrong amount.
  The common-sense solution might be to tell the member they sent an incorrect payment and ask for a correct one. Sadly the membership organisation doesn't want to do that, they want to record that an underpayment or overpayment was made and carry this forward.
  They also want to be able to report on a set of contributions, seeing the amount due and the amount received.
  I know that there have been relevant changes to Civi core as part of the CiviAccounts project, e.g. Phase 1 Implementation - Data Structure Changes, aimed at distinguishing 'commitments to pay' from 'payments'. I understand that some parts have been implemented, e.g. partial payment for events, but others not.
  What isn't clear to me is whether or how this infrastructure can be made use of in current Civi 4.6 for the above scenario. Or whether, as things stand, we need to use an alternative approach such as...
  
  Add a custom field on Contribution for Amount Received.
  Add a custom field on Contribution for Amount Over/underpaid.
  Record a separate positive or negative contribution for over or underpayment.
  Suggest that this information is best recorded outside Civi, in an accounts package.
  
  This section of the CiviContribute documentation sounds relevant:
  
  For example, a fund raising dinner that charges $100/person may now
    allocate the true costs toward the relevant accounts i.e. $75 donation
    posted to the Income account named "Donations" and the $25 Cost of
    Sales account to "Event Fees".
  
  However I'm not clear whether that is the right thing to do in this case or how the person recording the payment would do it.
  CiviCRM 4.6, Drupal 7.
  Edit 31 July 2015: adding relevant details of the use case, which I foolishly omitted to keep things simple...
  Each contribution may actually cover several items: 2 memberships, donation, fees, recorded with different financial types via price sets. The membership organisation wants a report showing, for each contribution, the membership, donation & fee elements as well as total due, amount received and amount of any over/underpayment.
  I like the idea, in @username_2's answer, of changing the contribution amount from e.g. £100 to £90 when the £90 cheque is received: looked like this might allow a custom report to compare amount due (from line items) with amount received. Sadly the contribution edit form doesn't allow changing the contribution amount when the contribution has line items. I tracked this down to templates/CRM/Contribute/Form/Contribution.tpl, line 97:
  {if $action eq 2 and $lineItem and !$defaultContribution}
    (...then view total instead of showing edit field...)
  
  I assume this was done for good reason: Civi wants to keep the contribution amount consistent with the line items and it wouldn't know which line item to alter. So for underpayment, looks as though the admin would need to record an additional negative contribution for the amount underpaid.
  
  **Tags:** civicontribute, civireport, accounting
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-07-24. Score: 4
  
  With respect to the overpayments, I don't know whether this will fit standard British accounting practices but I'd be inclined to create a separate financial type for the overages - a holding fund, if you will - and record one payment for the membership fee and one for the overage. They could then add an adjustment transaction the following year to move those funds from the overage account to the subsequent year's membership fee; that would make what happened and why abundantly clear to any auditors who review the financials later. That would also enable searching/reporting on that financial type. (I have at least one client that does this when they receive overpayments.)
  
  Regarding underpayment, perhaps the membership could be kept in pending status until the total amount has been collected; those pending members could be added to a smart group that could be used to filter contribution reports to find how much they've paid toward their membership, send email reminders, etc.
  
  That may not get you 100% toward where you want to go but hopefully it's a start.
  
  
  ---
  
  ### Answer by username_2 on 2015-07-25. Score: 2
  
  The quote from the documentation is perhaps alluding to the fact that you can create a price set where the various options can be allocated to different financial types, but I don't believe it is relevant for your situation where you already have a contribution record for the membership.
  
  I agree with Lesley's suggestion of a separate financial type for overpayments.
  
  If you don't want to keep a membership that is underpaid as pending then my non-code solution for underpayments would be as follows (assumes financial type for membership payments is Member Dues):
  
  * Create an "Overdraft" financial type
  * Create a new payment instrument of "transfer"
  * When a cheque comes in for less than the full amount:
    + Record the cheque against the pending contribution changing it to completed
    + Record contribution for the amount not paid with financial type of "Member Dues" and paid by "transfer"
    + Record contribution of -(amount not paid) with financial type of "Overdraft" and paid by "transfer" .
  
  [![Underpayment](https://i.sstatic.net/65C4V.png)](https://i.sstatic.net/65C4V.png)
  
  If you like to have every contribution with the financial type of "Member Dues" linked to an actual membership, then you can "renew" the membership to record the additional $10 "payment" then edit the end date appropriately.
  
  It is not exactly a speedy procedure, but does mean that the contribution records reflect the true situation.
  
  > **Comments:**
  > **username_0**: Many thanks username_2. Each contribution may actually cover several items: 2 memberships, donation, fees, recorded with different financial types via price sets. Membership org wants report showing, for each contribution, the membership, donation & fee elements as well as total due, amount received and amount of any over/underpayment. I like the idea of changing the contribution amount from e.g. £100 to £90 when the £90 cheque is received: this allows comparing amount due (from line items) with amount received. Sadly Civi doesn't allow editing the contribution amount through the UI in this case.  
  > **username_2**: Although you can't modify the amount of the price set you could still work out how much was actually paid. It will be the the amount "received" for the Dues, plus the amount of the "overdraft" (which will be a negative amount.)  The "total contributions" for an appropriate time interval will give you that amount.  
  
  ---
  
  