“Book ‘em, Danno,” -- Steve McGarrett, Hawaii Five-O
Some organizations post all pledges to the general ledger. Some post no pledges to the general ledger and track pledges receivable annual via a report run from their fundraising system. And others send “material” pledges to the general ledger and do not post smaller pledges, like annual pledges.
If you are an organization that books all pledges, that’s pretty straightforward. If you are an organization that books no pledges, that is also straightforward. But what if you are an organization that books some, but not all pledges? How do you ensure that only some pledges are posted to the general ledger? And how do you ensure that pledge payments get sent to the general ledger appropriately, depending on whether they are made against a bookable or non-bookable pledge?
One way to do it is through a customization. There are pros and cons to customizations, and sometimes they are absolutely necessary, but there is a way to make the sometimes-pledges-are-bookable-and-sometimes-they-are-not scenario work without customization.
In the general ledger transaction mapping area, you can map how pledges are sent over to a GL. You can use pledge subtypes to identify which pledges are bookable - or will be posted and which will not be posted. For example, no pledge subtype at all could be used where the pledge is not going to be posted, and a value of “bookable” or “material pledge” or whatever term your organization uses, could be used to signify pledges that should post to the general ledger. Or you could make pledge subtype a required field, and have two values: “bookable” and “non-bookable”. In either case, the pledges with one subtype will post to the general ledger and the ones with no subtype or “non-bookable” subtype will not.
That takes care of the pledges. But what about the payments on the pledges? You may have noticed that there is not a way to distinguish “flavors” of pledge payments in the transaction mapping area of the general ledger. It’s either a pledge payment or it’s not. This is where the revenue category field on transactions comes in handy. The revenue category field appears on both pledges and payments. The value on the pledge is inherited by the payment associated with it. So if we have a revenue category on a pledge of “bookable”, a payment to the pledge will inherit a revenue category value of “bookable”. If the revenue category on the pledge is blank or says “non-bookable”, any payment to that pledge will also have a revenue category that is blank or “non-bookable”. You can use the revenue category as a “switch” in the gl account string that means “bookable” or “non-bookable”, and then alias the account number to get rid of the switch and enter the “real” account number. (Tip: If you're not familiar with account alias on GL accounts you should get to know them becuase they're a powerful tool.)
You will also need to control how write-offs are done. You cannot control write-offs for pledges using pledge subtype like you can for sending the original pledge to the general ledger in the first place, so you will have to have “bookable” and “non-bookable” versions of your write-off reasons so you can control whether write-offs hit the general ledger or not.
To summarize, you will need to use pledge subtypes, revenue category and write-off reason codes to help drive the general ledger posting process:
The pledge subtype controls how the pledge itself is posted (or not), the revenue category controls whether the pledge payment goes in as an outright gift (because the pledge didn’t post), or credits pledges receivable, and the write-off reason code controls whether a write-off hits the general ledger or not.
To see some examples of this process in action, or to discuss how something like this might work for your organization, contact us today! To learn more about Brightvine, and take advantage of a complimentary, no obligation assessment, contact Stacey Segal today via email or phone: (843) 900-4287.