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.
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: http://forum.civicrm.org/index.php/topic,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: https://civicrm.org/blogs/pogstonesarahgladstone/creating-accounting-batch-export-format-accountedge )
- 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, Authorize.net, 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"