Introduction

In the context of data management for organizations and their relationship with clients and partners, there are currently several options available that suit the daily organization's work. Salesforce is the market-leading and most complete CRM platform, cloud-based, which allows to manage customers and partners, sales processes, leads generation, financial management and work on many other organization areas. The platform, in addition to these base capabilities, allows the integration with external entities, through API/Web Services such as Document’s certification, ATM payments and even Banking Services.

In order to improve these Salesforce base capabilities there are applications that can be purchased and installed from the AppExchange, the Salesforce app Store, such as FinancialForce.

FinancialForce allows account management, invoices generation, cash, collection cases, accounting reports generation and many other key features for a good and correct financial management of one or more companies (On the website appexchange or FinancialForce can be found more detailed product information). However, even despite the large number of existing applications, what is available is not always suited to the vision and organizations needs being necessary adaptations/implementations and improvements to the existing ones.

In this article we exemplify a case implemented in a client, where FinancialForce was leveraged for Cash Management by automating processes and improving financial indicators.

 

Important Concepts

SIN – Document representing a Sales invoice;

SCR – Document representing a Sales Credit Note;

Cash – Document representing payment received by Direct Debit;

Cash Refund – Document representing the failure of the billing attempt or the withdrawal of a Direct Debit received payment;

JNL ATM – Document representing a payment received by ATM;

Allocation/Association/Cash Matching - Operation of connection between two documents that indicates that, e.g. the payment received (Cash) was used to pay the sales invoice (SIN). Uses the FinancialForce CODAAPICashMatching_7_0.Match API;

Unmatching – Unlinking operation between two documents that were previously associated as e.g. a payment received (Cash) that was paying a sales invoice (SIN) when unmatching is done the invoice becomes unpaid and the payment available to pay any invoice from the same account.

 

Context

The organization, in example, uses FinancialForce on a daily basis for the financial and accounting management of contracts signed between clients and vendors, from issuing invoices or sales credit notes, sending for collection and registering payments in the system, either by Direct Debit, Bank Transfer and ATM Payment. In view of what is provided by the FinancialForce application, there was a need to improve and automate the management of the allocation of payments received with the main objective of not only reducing the accounting manual work, optimizing time and resources, reducing human errors of manual actions, adapting the process to current legal needs, and also improving the DPD indicator (Number of days that an invoice is unpaid after the due date - very important indicator for new company investors) from clients, as they had recent invoices paid while there were older unpaid invoices.

 

Survey of needs

After an analysis of the organization’s data and operation method it was identified that:

• The allocation of a Cash was always to the SIN which had originated the payment;
• For the same contract there were recent SINs Paid and old Unpaid which as increasing the DPD (days past due) indicator;
• Manually created Cashs and JNL ATM were manually allocated;
• Cash Refunds were being manually associated with Cash;
• Credit Notes were rarely allocated to the original Invoice (they should legally be associated). They were usually being allocated with Cash Refunds where the Credit Note value was being refunded to the client.

 

Intended Improvements:

• Reduction of the DPD indicator value (starting to allocate the received Cash always to the oldest SINs, of the same contract);
• Improve the efficacy of the Financial Team, releasing them from repetitive tasks, increasing the availability to focus on process improvement;
• Reduction of the manual process;
• Mitigation of errors in the allocation of payments;
• Association of Credit Notes by Cash Matching always with the respective invoice;
• Cash Refund must be paid (associated by Cash Matching) with the respective Cash that was withdraw(refunded);
• The Cash must be allocated to SINs of the same Contract and Account.

 

Strategy

            Initially, the possibility of using the FinancialForce’s BackgroundMatchingService service was evaluated to perform the automatic allocation between payments and invoices, however after some validations were identified some handicaps in the service that prevented the use it:

• The service only works if in the documents sent to it, the amount to be paid and payment amount are the same;
• Only allocates Cash with SINs (Not applicable to JNLs ATM, SCR and others);
• It’s not possible to define that the allocation between payments and invoices must be performed by Account and Contract (It’s only possible to define by account).

Due to the identified handicaps for the BackgroundMatchingService, it was decided to create, from root, an automatic process that fulfilled all the intended improvements. This process should run daily and several times a day in order to catch all Cash, Cash Refund, SINs, JNLs ATM and SCRs that appear during the daily operations.

 

Implemented Approach

            With the use of the Apex Language, an object-oriented programming language developed by Salesforce.com that allows the execution of flows and control of transactions on the Salesforce platform, the automatic process was divided into 3 Batches that correspond to 3 automatic phases of the process. This three-phase division allowed not only to sequence the process in phases that can be performed independently, but also to increase the processing speed/capacity while respecting Apex Governor Limits and FinancialForce Limits.

 

Phase 1: Batch BAM Refund

Direct Debit Cash Refund will now be automatically allocated to the respective Cash. The Cash Refund amount is then withdrawn from the invoices with the most recent due date of the account/contract to pay the invoices that were previously being paid by the refunded Cash.

Logical sequence implemented in the Batch:

1. 1. Identifies all Cash Refunds to be allocated in the system;
   2. Identifies the corresponding Cash to each Cash Refund;
   3. Evaluates if the Cash is being used to pay any SIN: 
   1. 1. i. In case of Cash is being used:
         1. Unmatch the Cash from the SINs that it was paying;
         2. Identifies the latest SINs that totalize the Cash amount and disassociates (Unmatch) the SINs from the respective Cashs/JNLs ATM, taking into account the Account and Cash Contract. (It will allow case like Cash Refund is related to a Cash that is paying an old SIN, that in the 3rd phase/batch the oldest SIN will be Paid and most recent ones Unpaid);
2.     d. Allocates Cash Refunds with the corresponding Cashs;

 

Phase 2: Batch BAM Sales Credit Note

The Credit Note will now be always allocated to the original Invoice. The payment that was previously allocated to the invoice is used to pay the remaining contract invoices.

Logical sequence implemented in the Batch:

1. 1. 1. Identifies all SCRs to be allocated in the system;
      2. Identifies the corresponding SIN to each SCR;
      3. Evaluates if the SIN is paid with Cashs/JNLs ATM: 
      1. 1. i. If the SIN is Paid:
            1. Disassociates (Unmatch) the SIN from the respective Cashs/JNLs ATM. (In the 3rd phase/batch the payment available will be used to pay other invoices from the same account and contract);
   2.     d. Allocates SCR with with the corresponding Invoice;

 

Fase 3: Batch BAM Invoice

Direct Debit (Cash) or ATL Reference (JNL) payments are now allocated to the customer’s account and contract invoices, taking as first priority the invoices with collection cases and the oldest due date as second priority.

Logical sequence implemented in the Batch:

1. Identifies all available Cashs/JNLs ATM;
2. Identifies all SINs (Unpaid/Part Paid) with unpaid value ordered, firstly by those with collection case, and secondly, by the due date from the oldest to the most recent ones;
3. Group payments and invoices by Account and Contract;
4. Performs the distribution of Cashs/JNLs ATM by unpaid invoices considering the ordering and grouping of invoices from previous steps;
5. For payments where cannot identify the respective contract, if the client has only one contract the payment is allocated to the invoices for that contract, if the client has more than one contract an issue is created for responsible team analysis.

Validations were introduced in all process phases, which in failure event an issue is created for the responsible team analysis, which allows identifying unexpected manual interactions such as manual dissociations between payments and invoices and errors from the other processes that already existed but had never been validated/identified that may affect the algorithm, such as the example of:

• Received Payment amount different from what was charged;
• Received Payment without being associated with any Payment Collection;
• Payments available without Unpaid invoices;
• Cash Refund of a payment that does not exist in the system;
• Credit Notes without invoices.

 

For the registration of all allocations/dissociations performed by the process was created a new custom object that along the algorithm is filled with relevant information by interaction, which will allow not only to have a history of the actions performed but also increase the performance of the research of the allocations to perform their dissociations (Unmatch). We have as an example the following object fields:

• Cash Matching Reference;
• UndoMatch Reference;
• Id of the Payment;
• Used payment amount;
• Account;
• Contract;

 

Functional Demonstration of Implementation

Cash Refund

Example of Cash Refund for Cash 1 with an amount of 200€ that was paying the invoice SIN1.

 

• Before the implementation of the new algorithm

The Cash 1 for which the Refund was made (Cash Refund 1) was disassociated from the invoice that was paying SIN 1 and the same remained Unpaid. As in this case there was a more recent invoice that SIN 1 the DPD was going to increase.

 

• After the implementation of the new algorithm

The Cash 1 for which the Refund was made (Cash Refund 1) is disassociated from the invoice that was paying SIN 1, the same amount is disassociated from the most recent invoices Cash 2 and this payment is used to pay the invoice SIN1. In this case we always get the older invoices paid, thus reducing the DPD.

 

Sales Credit Note

Example of a Sales Credit Note for SIN 1.

• Before the implementation of the new algorithm

When a Sales Credit Note (SCR 1) was created for an invoice (SIN 1) if the invoice was already paid (Cash 1), a Cash Refund was manually created to return the money to the client.

 

• After the implementation of the new algorithm

When a Sales Credit Note (SCR 1) is created for an invoice (SIN 1) the invoice is disassociated from your payments, paid with Credit Note (SCR 1) and the payment that were previously allocated to the invoice are used to pay other invoices (SIN 2 and SIN 3) of the client’s contract thus reducing the DPD, manual interaction and no more refunds of money to the client with invoices in debt.

 

Invoices

Example of a 250€ payment received.

 

 

 

 

 

 

 

 

 

• Before the implementation of the new algorithm

When receiving a payment by Direct Debit (CSH 2) or by ATM Reference (JNL ATM) it was always allocated to the invoice (SIN 2) that gave its origin, and there may exist older Unpaid invoices (SIN 1) thus increasing the DPD.

 

 

• After the implementation of the new algorithm

When receiving a payment by Direct Debit (CSH 2) or by ATM Reference (JNL ATM) it will be allocated to the invoices in ascending order of the due date, in this case, from Cash 2 of 250€ was used 200€ to pay SIN 1, being fully paid, and the remaining 50€ was used to pay a portion of the invoice SIN 2. With this logic we will always have the DPD indicator with the lowest possible value.

 

 

Conclusion

With the implemented algorithm, the FinancialForce was leveraged for the automatic Cash Management, fulfilling not only all the needs of the organization to improve the DPD indicator, release manual resources allocation, and automate the entire payment process, but also identify errors and accounting failures in the system. Currently the implemented algorithm is fundamental for the system accounting and collection operations.

 

References

1. Community Financial Force(https://erp.force.com/community)
2. Automating Cash Matching (http://developer.financialforce.com/technical-reference/automating-cash-matching/)
3. Accounting API Developer's Reference (https://help.financialforce.com/accounting-api/15X/Default.htm)