Context
As an accountant in an organization (e.g. where there is an association and a foundation), the goal is to be able to identify "due to" and "due from" information for transactions. That way, accountants can balance the money that one financial body owes to the other, or is expecting from the other into their accounting software.
Prior to Cobalt 4.1, the system created general ledger entries by product, but it assumes the association collects all the payment. It can’t show when part of the payment belongs to another entity (like a foundation). For example: During membership renewal, the association collects dues and a foundation donation. The donation money really belongs to the foundation, but Cobalt records it as if the association collected it all, making reconciliation difficult in eCommerce transactions.
In Cobalt 4.1, we have introduced multi entity accounting so that an order that has products for two or more distinct financial entities, are supported by the system. We have added logic for generating GL entries.
If there's a Product GL Account with type 'Receivables' configured, and its GL Account has a Financial Entity set, and that Financial Entity is different from the default one on the Settings record, then we will make these two GL Account Entries:
-
"Due From {the default financial entity}"
GL Account = the configured Financial Entity's Due From account
Type = Debit -
"Due To {the configured financial entity}"
GL Account = the configured Financial Entity's Due To account
Type = Credit
New Entities and Fields:
1. In the eCommerce module, there is a new entity, "Financial Entity" with the following fields:
- Name (primary text)
- Description (multi-lines of text area)
- Prefix (text)
- Due To (lookup to GL Account)
- Due From (lookup to GL Account)
Batch records will now also have a new “Financial Entity” lookup field, to identify what financial entity a Batch's items should be affiliated with.
General Ledger Account records will also have a lookup to the Financial Entity, as well as a new account type: "Asset".
Product records also have a new “Financial Entity” lookup field added, so that specific Products can be associated with a specific Financial Entity.
On the Settings records, there is a "Default Financial Entity" lookup field. Set the financial entity that all products, unless specified otherwise, should go to.
Example Setup (With 3 Financial Entities)
Pre-requisites:
- 3 Financial Entities:
- e.g. Cobalt, Foundation, and Education
- Set the Due To and Due From as the following:
- Cobalt (default financial entity):
- Due to = Cash GL Account
- Foundation and Education (not default financial entity):
- Due To = Liability GL account
- Due From = Asset GL Account
- Cobalt (default financial entity):
- With the Due To/Dues From GL Accounts as the following:
- "Due From" GL Account record, where Account Type = Asset and Financial Entity = the non-default entity (e.g. Education)
- "Due From" GL Account record, where Account Type = Asset and Financial Entity = the non-default entity (e.g. Education)
- "Due To" GL Account where Account Type = Liability and Financial Entity = the default entity (e.g. Cobalt)
Setting up the 3 Products:
- Product's "Financial Entity" lookup is set to whichever financial entity the funds should go to.
- Product records for testing should be set up so that they have related Product GL Accounts, where the related General Ledger Account has the appropriate Financial Entity record set (to indicate what financial entity will have funds owed).
- Example: "Contribution" Product has related Product GL Account records tied to the Donations Revenue / Donations AR accounts. The Donations Revenue / Donations AR accounts are set up so that they are tied to the non-default Financial Entity, indicating that funds will be owed to that organization.
- Example: "Dues" Product has related Product GL Account records tied to the Dues Revenue / Dues AR accounts. The Dues Revenue / Dues AR accounts are set up so that they are tied to the default Financial Entity, indicating that funds don't need to be owed to an organization.
Example:
- Create an Order for a Contact with 1 Product tied to the default Financial Entity (ex. Cobalt) and 1 Product tied to each of the non-default Financial Entities (ex. Foundation and Education).
- At this time, no GL Accounts are created.
- Create a Payment for that Contact, for the amount of the Order that was generated.
- At this time, default Payment GL entries are created.
- Apply the Payment to the Order (using the Payment wizard).
- At this time, the default Payment GLs are canceled out, Product-specific GL entries are created, AND a "Due From" debit entry is created and a "Due To" credit entry is created for the amount of the Product(s) tied to the non-default Financial Entity.
- In the Batch records generated from the transaction:
- The prefixes set (the "Code" field) on the Financial Entity records prefixes the appropriate Batch. There should be corresponding Batch records for each Financial Entity, identified via the prefix. (e.g. there should be a PMT batch for the default Financial Entity and a PMT batch for the non-default, prefixed by the code set - "FND-PMT" and "COB-PMT").
- Open a Batch record.
- See that the Financial Entity set on the Batch record matches the prefixed Batch name.
3. Lastly, once the batch has posted, we can run the General Ledge Batch Distribution Report.
4. Review the report and see that the 3 Financial Entities are generating the correct GL entries, batches, and batch items.