Welcome to the SAP-Centric Financials blog! As we embark on launching our inaugural program next February, we’re excited to also launch our blog series, featuring a number of industry thought leaders offering insight and advice on some of today’s most pressing finance topics.
Have you considered the type of payment received and subsequent cash application process could either increase or decrease your DSO? How is this possible?
Historically, checks were used so companies to increase float by several days due to mail processing time. Checks continue to be used for practical reasons often due to remittance limitations on electronic formats. ACH, wires, and credit card payments all have their own remittance nuances. The classical banking system was optimized for a system that utilized checks heavily. Its transformation to electronic payment formats is underway.
In the US, many companies are focusing on increasing the percentage of electronic payments received. It is common to see projects that convert customers from checks to ACH or other electronic payments. For companies with heavy lockbox volume, there is a 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 important considerations:
- Implications on cash application process by receiving electronic payments such as ACH or wires.
- Nuances of credit card payments, portals and invoice clearing. Implications on cash application process
Receiving payments is the first step of the cash application process. Ensuring that those payments are applied to the appropriate customer and clear the appropriate invoices and credit memos is the second set. Receiving payments electronically is the easier part of the transformation process. The application to the customer account is the more difficult part. Consider the following:
- How can you automate cash application into your SAP system? Many companies automate lockbox processing. Do you have automated processing and application for electronic bank statements to clear the customer account?
- 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?
Finally, consider that wire payments will not have the same remittance structure as an ACH payment, as these are different types of payment with different limitations.
- 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.
- Optimizing for electronic payments can also warrant consideration for 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 processing 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.
Payment choices can impact your DSO. Consider the ramifications of these choices as conversion to electronic payments is pursued to ensure no unintended consequences or added process complexities.
Written by: Amber Christian
President & ASUG Finance SIG lead
