Have you considered that the type of payment you receive, and the subsequent supporting process, could either increase or decrease your DSO? How is this possible?
Historically, checks were used so companies could increase their float by several days due to mail processing. Checks are continued to be used nowadays for practical reasons; checks are used due to remittance limitations within the systems of the company issuing the check. Most companies include remittance information on the attachment to the check. However, ACH, wires, and credit card payments are a little different and each have their own remittance nuances. The classical banking system was optimized for a system that utilized checks heavily.
In the US, many companies are focusing on increasing the number of electronic payments received. It is typical to see projects focused on converting customers from checks to ACH or other electronic payments. (Click here for our blog on Same-Day ACH.) For companies with heavy lockbox volume, there is a perceived benefit to receiving electronic payments in order to reduce check processing fees as well as to receive the cash faster by eliminating mail float. Before simply flipping the switch and moving all customers to electronic payments, there are some important considerations:
1. Implications on cash application process by receiving electronic payments such as ACH or wires.
2. Nuances of credit card payments, portals and invoice clearing.
If you will convert customers from sending checks to ACH, how will you receive remittance information in order to automatically apply payments? There are technology aspects that need to be carefully considered during this type of change, particularly as it relates to remittance. Without considering the remittance processes, you could find yourself going backwards in speed of cash application, and actually increasing DSO instead of decreasing! In order to prevent this, consider these aspects:
- How are you going to process payments into your SAP system? Many companies automate lockbox processing, but may not automate their electronic bank statements.
- Does your banking partner offer services that will send the remittance information in a lockbox or other interpretable format for automatic cash application in your SAP system?
- If remittance information is provided, is it actually normalized into a structure that will post into your system automatically, or will you be required to perform pre-processing to use the data? Within the ACH world, you may find yourself contending with CCD, CTX, PPDand other ACH addenda formats. CTX is a heavily used ACH remittance format. However, while CTX has standards, there is variability in what each company actually sends in their CTX structure. How will you manage this variability if it is not normalized?
- Will the electronic payment and remittances be included on your BAI2 or other bank statement formats? Are you even loading a bank statement into your system today to automatically clear invoices from the AR sub ledger as well as post other bank transactions?
- Can the bank statement format you are currently using, or plan to use, supply enough places to include all the necessary remittance? There are practical limitations on the amount of data that can be passed on your BAI2 format. This may require you to assess newer formats such as CAMT053 XML, assuming your banking partner can take advantage of past remittance into the enhanced remittance structure.
- Those optimizing for electronic payments can also further consider newer technologies such as virtual account solutions. These solutions can be used to provide an association between your SAP customer master data and the customer. This can allow faster association of payments to customers.
Nuances of credit card payments, portals and invoice clearing
Adding credit cards as a payment channel can provide ease of use and offer greater flexibility for customers, particularly small customers. Processing fees on cards can be weighed against the amount of time to chase overdue invoices for small customers.
A practical challenge for many companies is handling credit card information. Few want to store this information in their systems for security reasons. This often means integration with third parties to support processing credit card transactions.
The end-to-end process for credit cards needs to consider both the technology involved as well as the business process to support invoice clearing. How will you clear invoices from AR, and how you will automate and clear the actual credit card deposits? Will you receive detailed information in a formatted file that your system can read, or will you be required to clear manually?
A proper structure and process in your SAP system will ensure you can easily identify credit card declines or other proc
essing problems. Declined credit cards that show as processed AR artificially stated DSO as too low. While it would be unusual that this would be a significant size, reconciliation still must be in place to catch and correct errors.
We've touched on high level aspect of how payment choices can impact your DSO. Consider the ramifications of your payment choices as conversion to electronic payments is pursued to ensure you do not have a side effect of increased DSO and cash application process complications. Appropriate analytical applications can help gain visibility to these payments and understand their overall impact. Stay in touch as I will be writing on this topic in future blogs.
