Aller directement à la fin des métadonnées
Aller au début des métadonnées

Purpose of this page

To document, discuss, and prioritize next steps for CiviAccounts.  CiviAccounts refers to the features of CiviCRM that impact financial reporting, searching, reconciliation processes, and integration with third-party general ledger software.  In some cases, this impacts the use of pricesets and payment processor integration.

A tremendous amount of work from many people, many organizations and many budgets has gone into getting CiviAccounts to where it is today. CiviAccounts also has tremendous potential and hopefully with some straight forward changes, it can be even better. 


 Before CiviAccounts, pricesets could only have a single financial type. Pricesets could not be used with automated repeating contributions, key data needed for reconciliation and general ledgers was not available. Financial data was spread out in multiple core tables, which made reporting difficult. Standard accounting practices (such as an audit trail) were not available. Not only have all those limitations been removed, CiviCRM now has features for partially paid event contributions, an expanding list of payment processor extensions, payment processors offer advanced features such as DirectDebit, swipe devices, and more. 

Why Now

In a number of forum posts, email discussions, survey results (Pogstone conducted a survey of all our clients), and face-to-face discussions at CiviCRM gatherings, I have learned that there are a number of barriers to using CiviAccounting features at all for many organizations. Instead they use a patchwork of custom reports, custom searches and manual steps outside of CiviCRM.  This prevents knowledge sharing, best practices,standardized documentation, extensions, etc from being shared across multiple organizations using CiviCRM.    It also means when an issue arises in CiviCRM core, there is less consensus on how to change that area, since each organization is relying on different assumptions about core accounting features/tables in CiviCRM.    These issues may also prevent some organizations from adopting CiviCRM in the first place, if a key requirement for their CRM is that it have strong support for standard accounting processes and strong integration with general ledgers. If they hear from other organizations that to integrate with a common general ledger requires many custom reports, manual labor, etc they may rule out using CiviCRM entirely. 

Common Show Stoppers

This is a list of minimum requirements to use CiviAccounts, that are currently unavailable in CiviCRM. These items prevent many organizations from using CiviAccounts. 

  • Class/subclass data is not available in the Bookkeeping Transaction Report or the export of accounting batches.  For organizations using QuickBooks and classes (which is a common feature in QB), this prevents use of exporting accounting batches to their QuickBooks general ledger 
  • The CiviCRM core API is broken for multiple line item contributions. The API does NOT produce valid data on the Bookkeeping Transaction Report and the export of accounting batches. (See discussion at:,35398.0.html  ) Currently this issue severly impacts organizations that use automated recurring contributions and pricesets. 
  • On the screen to choose which records to assign to an accounting batch, key columns are missing that allow the user to choose the right records to assign to the batch. ( ie credit and debit data, when there are multiple records listed for the same contribution. Such as when transaction/banking fees are recorded within the contribution) 
  • On the screen to choose which records to assign to an accounting batch, the filters only consider top-line contribution data. It does not allow for filtering on line item data, nor credit/debit data. (IMHO the filters should work like the filters on the "Bookkeeping Transaction Report" template. )  
  • For organizations using accrual accounting, pledges are not reflected in the Bookkeeping Transaction Report and the export of accounting batches. During a discussion at CiviCon in April 2014, the suggestion for this issue was to use pending contributions instead of pledges. However, pending contributions do not allow for payment plans, due date for the balance, and other essential features that pledges allow.  

Challenges Impacting Bookkeepers and Accountants

  • Configuration issues discovered (and changed) after a contribution has been recorded cause major headaches. For example:  A payment instrument is mapped to the incorrect asset account for 2 weeks. The issue is discovered when exporting an accounting batch to the general ledger.  After discovery, the bookkeeper updates the configuration for that payment instrument.  After that, the bookkeeper must hand-edit the general ledger entries. This is very labor intensive and leaves a lot of room for mistakes. 
  • Changes in how someone is paying creates a lot of manual labor and extra records. For example: A donor/member/participant has an open balance with an organization. (ie they have an open pledge, or a pending/partially paid contribution, or a completed contribution that failed later (ie a bounced check)) .   The donor/member may initially pay part of their balance using one method (such as mailing a check), but later on decide they want to pay off some or all of the balance using a credit card/DirectDebit payment. (Which could be one-time or automated recurring transactions) Or vice versa.  (This situation is extra painful for organizations using accrual) 
  • Adding a new Financial Type, and putting in the correct accounting code for the autogenerated Financial Account (of type Income) requires to many clicks/screens and its easy to make a mistake. 
  • CiviCRM permitted, but odd configurations result in unbalanced records on the  Bookkeeping Transaction Report and the export of accounting batches. In some cases, configuration choices prevent contributions from being listed on the contact contribution tab. 
  • None of the core-provided financial report templates (or core searches) provide reporting/filtering on financial types used within line items. This means there are no usable fundraising reports in CiviCRM for fundraising and financial users at an organization if they need to filter/see financial types. (and their organization is also using pricesets)   
  • The Bookkeeping Transaction Report has the ability to report on line item data, but only for one-time contributions, not automatically recurring (This is due to the contribution/line item API bug generating bad data). 

Challenges Impacting Developers, Implementers, and Administrators

  • To develop new accounting batch export formats requires hacking core. There is no way to package new batch export formats within an extension to share with others. ( see: )
  • Core CiviCRM tables/fields are used in different ways by different developers. This makes reporting difficult. For example: the AgileWare-developed eWay payment processor uses "civicrm_contribution_recur.installments" to indicate the number of future scheduled installments. (The extension changes the number after each installment is processed.) Other payment processors (such as PayPal,, iATS) use that same field to indicate the total number of installments overall. (completed or future)
  • There is no way in the Accounting Batch screen to save the preferences of the user who likely follows the same process for most batches. In order to provide a user a means of saving their filters/columns, the only option currently is to develop a custom CiviReport template. (Then the user uses the report template to export to their general ledger) 


Enhance the report templates to potentially replace or augment the UI under "Contributions ... Accounting Batches".  Since report templates can be packaged and shared as extensions, this gives a lot more flexibility to the community to be able to tailor the screens to support a specific process or general ledger product. 

  •  On the existing report template "Bookkeeping Transaction Report" add actions to the top that allow the user to add the records they see to a new or existing accounting batch.  This can serve as an example to developers who need to develop custom filters/layouts for other general ledger products or processes.
  •  Add new report templates for working with accounting batches, including the actions "Close" and "Export"


  • Aucun
  1. Jan 23, 2015

    Rob Brandt dit :

    Thank you for doing this Sarah.  We haven't gotten into data exchange between bookkeeping programs yet (QB Online in our case) but we are finding line item support inadequate.  Very few of our transactions are NOT complex, multi-item transactions.  So we are trying to standardize our CiviCRM usage based on line items.  However, there's major stuff missing:

    • Reports generally do not search line items.  Although Eileen's Extended Reports do, and are extremely helpful.
    • There is no way to import line items via the CiviCRM web interface.
    • You cannot search for line items via the CiviCRM web interface.

    These items need serious attention.

  2. Jan 26, 2015

    JoeMurray dit :

    Hi Rob Brandt,

    The CiviAccounts project had a constrained budget and was unable to do all that those involved including myself as lead wanted. As we have identified additional funding sources, JMA Consulting and WebAccess and the core team have been extending the work from 4.3 to 4.4 to 4.5 and now 4.6. For example, there was an EU VAT project last summer to improve core support for sales taxes, and I expect work we are doing collaboratively again for Canadian Sales Taxes will help creat a pattern for other places with multiple taxes on a single item (eg State and City taxes in the US). On a pro bono basis, JMA has also been supporting the core team in maintaining CiviAccounts enhancements past the agreed upon period. Pogstone also did one or two extensions I believe.

    Were Pogstone to consult with the core team or myself on possible improvements, and to submit patches changes to add hooks they need and/or extend the API, then so long as their code had adequate automated tests and met core requirements for coding style and quality I'm confident these enhancements would be accepted by the core team.

    I should say thanks to Sarah for the effort involved in collating ideas here for various enhancements. BTW, it might be good to share who wants what, Sarah, so that efforts to get MIH collaborations going would be facilitated. Did you have many respondents?

    If you had some resources, Rob, either in terms of funding or developer time, your three points are excellent do-able tasks. It might be least expensive to try to get improvements in Eileen's reports put into core. The core team is probably the best lead for enhancements to import code, though we could do it too if they are busy. We at JMA would be interested in taking on an enhancement to searches to support line items if resources are available.

    Thanks for the feedback, and best wishes.

    Joe Murray

  3. Jan 27, 2015

    Rob Brandt dit :

    Thanks, Joe.  We have more developer resources than funding resources available, I would say.  But it all depends on what the estimate of each item would be, and it seems to me that most efficient coder would be the ones who did the original work.  We have some extensions we are planning on contributing already, it's just a matter or priorities for us as well.  We need to focus on things that are unique to our needs if possible.  I see the needs regarding line item support to be very broad.  Of the things I listed above, if an organization is going to be using line items, they will all need those three things.


    (Botanical Society of America)

    1. Jan 28, 2015

      JoeMurray dit :

      Heh Rob, I've checked with Dave Greenberg about your comments and more broadly about this page.

      If there is some funding then I'm confident that Eileen, the core team, and / or JMA would be willing to provide some detailed technical specs (which files to change and how) and QA for things you would be interested in developing. Changes could be scheduled to go into 4.7 or 5.0.

  4. Feb 01, 2015

    Joe - Part of the purpose of this discussion is to hopefully get more budget $ from non-profits available to improve CiviAccounts. In regards to maintenance issues, I think it would be helpful to move some elements of CiviAccounts into extensions, so that those things can be improved without waiting for a new version of core. (ie batch export formats could be in an extension, or instead report templates could be used to get records into batches, and exported)

    What do you see as elements that must or should remain in core?