2

Suppose an organization's fiscal year ends December 31st, 2018. Organizations which operate on an accrual rather than a cash basis (most, in my experience) would recognize a check dated December 30th, 2018, that was not received until January 4th, 2019, as a 2018 donation.

On CiviCRM contribution entry screens, there are two date fields. "Receipt Date," the date that a receipt was sent to the contributor, is irrelevant to this discussion. The other is labeled "Date Received" and described as "The date this contribution was received." If data entry staff were to take this language at face value, they would enter January 4th for the donation in question, which would result in reporting (or accounting sync) inconsistent with the organization's accounting basis.

An obvious workaround is for staff to be instructed to enter December 31st as the "Date Received" for such checks. Is anyone doing something better than this?

2

CiviCRM 4.7 have accrual integration where you can specify Revenue recognition for a contribution. You can enable the 'Enable Deferred Revenue' setting by navigating to CiviCRM >> Administer >> CiviContribute >> CiviContribute Component settings.

Once you have enabled the setting you will need to create 'Deferred Revenue' relationship between Financial type and Financial Account.

On new contribution form once you have selected financial type you will revenue recognition field

enter image description here

Documentation : https://wiki.civicrm.org/confluence/display/CRM/CiviAccounts+Data+Flow#CiviAccountsDataFlow-DeferredRevenueImprovements

  • I'm marking the question answered since Pradeep shared a feature expressly designed to deal with this question, and provided detailed instructions, screenshots, and a link to further information. However, I think my initial workaround (echoed by @KarinG) is most appropriate for most of my clients. – universalhandle Nov 14 '18 at 16:28
2

Date Received as in date on the cheque (i.e. the date that someone started giving you the funds) works just fine.

All our larger organizations/clients do just that. I would recommend against making things more complicated by adding in additional / new / not much used functionality that you really don’t need to solve this problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.