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


This page is meant to give an explanation and describe various strategies/approaches for integrating CiviCRM and your general ledger. Once you decide on an approach, follow the links to the approach-specific documentation.


  • General Ledger software: A system that can track debits and credits ( ie the basis for double entry accounting) and can also produce typical accounting reports, such as a Profit and Loss Statement, Balance Sheets, Deposit reports, etc. General Ledger also is used for bank reconciliation processes by an organization's bookkeeper/accountant.
  • Chart of Accounts: The area within the General Ledger software where an accountant has set  up all the accounts used by an organization. Accounts can be income accounts, expense accounts, asset accounts, and other account types. 
  • General Ledger Software sub-modules: Additional software capabilities within the general ledger software package. Many general ledger software vendors provide submodules for payroll, invoicing, customer/donor tracking, credit card processing, and more.  Sometimes these are referred to as "sub ledgers"

Integration Approaches to connect CiviCRM and your General Ledger:

A) All donor/member/contribution details in CiviCRM sync to the General Ledger


  • If you are already using the general ledger sub-modules such as donor tracking, etc, then this approach means you are continuing to use those same sub-modules.  
  • All your summary data (such as Profit and Loss report) and all the supporting details are in a single place, which is your general ledger software with its sub-modules. 
  • If you get financial activity from systems other than CiviCRM, there is no need to enter that data into CiviCRM. (Such as a third-party point of sale system,building rental fees, etc)


  • The sub-module in your general ledger system may not be a good fit nor support all the advanced features of CiviCRM.  For example: CiviCRM soft credits, and multi-year capital campaigns may not be supported in the general ledger sub-module.  
  • The donor/member sub-module in your general ledger may not work well for tracking your donor's complex relationships. (ie 2 adult donors who are living together, but not married.  They each have children from previous relationships where special billing is needed, or tracking where they work for an employer-matching program.)
  • Troubleshooting is more complex. (What if CiviCRM has a different mailing address, email address, or phone number as compared to the record in the general ledger system? How is this researched? Who is responsible?
  • Too much detail in the general ledger  donor/member sub-module. For example: You have a large paid event that is open to the public, and 500 people paid. ALL the details for those 500 people will get transferred to your donor/member sub-module in the general ledger. Is this a good thing? 
  • Most general ledger sub-modules are designed for business. So you are trying to twist features deigned for a business into various work-arounds for a non-profit.  While payroll is payroll, donor management is NOT much like customer management. 

Overview of how to implement this approach:

You will need a robust CiviCRM extension that supports the general ledger software you are using, and matches HOW you are using the general ledger system.

To see the latest available extensions, check

For Xero:

B) Only deposit-related details from CiviCRM gets sent to the General Ledger


  • All the details about your donors/members/participants stays in CiviCRM, which is designed for non-profits and membership organizations. 
  • Easy to track and combine financial information with non-financial information: Such as which of your big donors are also volunteers and participants. Are any of your donors (who may owe money on a pledge) experiencing a serious illness, so its not a good time to ask for an overdue payment. 
  • Less data needs to be synced, therefore there is less to troubleshoot
  • Use features that are part of CiviCRM core - Click "Contributions ... Accounting Batches"
  • Typically, no extensions need to be installed. 
  • Your full communication history with a contact is in CiviCRM: Including thank-you notes, phone calls, volunteer signups, financial statements emailed, tax letters mailed, and all other communication and activities.


  • To view some of the details for a deposit (such as which donors were involved) its necessary to look in CiviCRM.  
  • If your bookkeeper has never used CiviCRM before, they will need to learn how to record contributions, etc in CiviCRM
  • This approach works best for organizations using "cash-basis" accounting. For organizations using "accrual-basis", this approach is more time-consuming.

Overview of how to implement this approach:

1) Make sure the following 3 areas are properly configured in CiviCRM: Payment Instruments, Financial Accounts, Financial Types

2) (Optional) If you accept credit cards and/or DirectDebit, make sure your payment processor (and its asset account) are configured properly in CiviCRM.

3) To prepare and export one deposit from CiviCRM: Click "Contributions ... Accounting Batches" OR "Contributions ... Batch Data Entry". See detailed instructions at:

4) For sanity's sake, review the exported Accounting Batch file.  If the data in the exported file looks wrong, its likely because something was overlooked in step 1.  

5) Once the batch is exported (typically to an IIF file for QuickBooks), launch QuickBooks and click "File ... Utilities ... Import from IIF"

Note: Steps 3-5 will need to be repeated for each deposit.  You should also review the page: Using CiviCRM as an Accounts Receivable System


C) Nothing from CiviCRM is sent to your General Ledger


  • The most simple approach
  • Nothing to troubleshoot
  • No extensions or configurations needed.
  • All financial reports (summary and details) are in one system: the general ledger system


  • Most donor/member financial data is absent from CiviCRM. No way to track which donors are also volunteers, event participants, etc.
  • Communication history is spread out across multiple systems. For example, you look in CiviCRM to see the last time a letter/email was sent to a person. But that does not show communication generated from the general ledger system
  • Donors/members end up being tracked in a general ledger sub-module that is designed for businesses, not nonprofits/membership-based organizations. 
  • Greatly increases manual labor needed monthly. Such as tracking event payments from hundreds of people, and trying to make sure they are recorded against the right person in the sub-module.



  • Aucun