Cash Flow and Strategic Partnering: Understanding What You Don't Control©2002 Business Credit Magazine
By Alan Mitchell
Thirty days have passed. Payment is still not received. With effort, you reach the accounts payable rep. When that accounts payable rep tells you that they cannot pay because the invoice is wrong or infomration is missing, it creates a long investigative cycle for you. The information for this research resides elsewhere with others within your organization. All of these errors were created upstream by other departments. Errors include price, quantity, under funded PO, planned returns, missing information, wrong line item numbers, etc - what you might characterize as Operational Transaction Errors. As business process complexity increases, especially with your most critical strategic customers, these Operational Transaction Errors are becoming a big driver of high DSO. The first step in reducing these Operational Transaction Errors is understanding their root causes.
Three large categories create these Operational Transaction Errors
THE COMMON ISSUES IN OPERATIONAL INTEGRATION
If only this were as simple as the customer generating a purchase order which was then perfectly captured into your systems as a sales order by the order administration group. In reality, the combination of (a) change orders (b) business rules, and (c) disparate systems creates upstream errors that inevitably will create a collections nightmare.
(a) Change Orders: Once a purchase order has been received and processed,
the corresponding sales order is then generated within your systems environment.
The problem occurs when your customer's requirements change after the
purchase order has been processed and they request a change in the volume,
a variation in the product configuration or a completely different product.
The sales order then needs to be changed to reflect the alteration, and
as this is usually a manual process, errors can occur.
Due to the strategic nature of the customer, order administration will be focused on getting orders through as fast as possible at the expense of order accuracy. Although the fulcrum for the speed and accuracy balancing act is invariably determined by the customer, experience in tracking these types of errors reveals that the discrepancy rate between change orders and sales orders are typically 20-40%.
(b) Business Rules: For every business, there is a set of rules that
determine product configuration, discount structure, terms, payment processing
and distribution handling. The rules are then applied by product, customer,
line of business or geography. If these rules are embedded in the application
layer then the systems environment will automatically apply the appropriate
In some organizational structures, the order administration department
rolls up into the sales structure to promote synergies between the two
departments in the form of transparent business rules. In other instances
the business rules are not visible to order administration and result
in pricing, quantity and configuration disputes.
As a result of risk sharing initiatives and tailored solutions, strategic customers usually have a more complex set of business rules that differentiate their relationship from other customers. Misapplied business rules result in disputed invoices, credit memos, Return Merchandise Authorizations (RMAs) and account reconciliation.
(c) Disparate Systems: In the event that purchase order data flows from an EDI exchange or from a quoting tool, there is the chance that variations may exist between the structure and content of the order once transferred between applications. This occurs due to three main reasons.
Format Manipulation: The format of the purchase order or quote is manipulated once transferred between applications to suit the technical requirements of the order entry mechanism. For example, the EDI purchase order may contain one product with five options under the product configuration but once processed the sales order and invoice show six products.
Content Transfer: Partial information is transferred from the purchase order or quoting mechanism application that is then auto populated in order entry. For example, the part number, quantity and the customer number would be transferred from the EDI purchase order into order entry where the price is then calculated based on the customer number and part number.
System Limitations: Specific data requirements are not aligned between the purchase order or quote mechanism and order entry. This can range from rounding issues stemming from decimal point constraints or part numbers that cannot be processed by order entry. For example, your customer's purchase order application may be incapable of generating part numbers with a backslash or dash and as a result, order administration is tasked with identifying these types of constraints and modifying the part number prior to generating the sales order.
Order Fulfillment encompasses the series of process steps that occur once the sales order has been created to signed acceptance of the POD. There are two critical components of order fulfillment:
(a) Traffic: Improvements in manufacturing and distribution software
have lead to vast reductions in the problems associated with distribution.
The majority of traffic related discrepancies have been caught through
multiple quality checks, scanner guns and warehouse management software
improvements, but errors do still occur around quantity and product accuracy
due to the manual component.
Partial shipments: Partial shipments are usually agreed upon upfront in the negotiations process with strategic partners, but change depending on requirements. For example, it may be agreed that partial shipments will not be accepted unless requested via email for specific deliveries. In some instances this creates confusion that results in an incorrect partial shipment along with an invoice that does not match the purchase order resulting in a withheld payment.
Substitutions: Substitutions may occur when a product has been end-of-life'd or a stock out occurs on an urgent order. As a result, accounts payable may not have been informed by the buyer of an agreed substitution which then results in a withheld payment.
(b) Returns: Returns are considered part of the Order Fulfillment process as they represent a reverse fulfillment. Typically, a Returns Merchandise Authorization (RMA) is raised by order administration or collections that then results in a credit once the RMA is fulfilled. Frequently occurring RMA discrepancies are usually due to price book changes that occur between the date of the invoiced price and the date of the credit memo amount. Also, distribution is more focused on delivery than RMA processing and as a result a customer may withhold payment until an overdue RMA related credit has been generated.
The Service Level Agreement (SLA) of strategic partnerships may allow the customer to return slow moving stock or over stock allowances. For example, the detail of SLAs may allow the customer to return goods for the purchase price excluding freight charges if returned within a specific timeframe, outside of which the customer pays freight.
Without strong operational integration, managing RMAs can be a complex process that results in withheld payments and operational overhead in providing the expected level of service.
In a perfect world payments would be made in full, on time and against the corresponding invoice. Unfortunately this is not the case. Two typical problems arise in processing payments, or the lack thereof, within collections and cash application:
(a) Bulk Payments: Due to the invoicing frequency of strategic partnerships,
customers are more willing to make bulk payments against a series of invoices
rather than individual payments on an ongoing basis. In the event that
a bulk payment is made along with a sequence of deductions, it becomes
a reconciliation exercise in correctly applying. As a result, the collections
department spends more time reconciling accounts than collecting.
Strategic partnerships require a high degree of accuracy when applying cash due to the volume of customer specific payments and the impact if unresolved.
(b) Dispute Management: Most companies that embark on a DSO reduction
initiative focus their attention in the collections department. One of
the outcomes of this type of initiative is a dispute management process
that seeks to identify the reasons associated with late paid invoices.
Disputes are then escalated to the person in the company best positioned
to resolve the dispute to the satisfaction of the customer. The objective
is three-fold, root cause identification, root cause elimination and dispute
cycle time reduction.
Root Cause Elimination: As every Controller or Collections Manager knows, collections is rarely able to influence the sales or order administration processes such that sustainable change is implemented in eliminating the source of disputes.
Dispute Cycle Time Reduction: The implementation of a dispute management process does have an impact on reducing DSO but only to a level dependent on the reaction time of other departments in resolving disputes and on the collections department in identifying disputes.
Ultimately, dispute management is a reactive process that identifies symptoms rather than root causes and very rarely results in successful root cause elimination efforts.
The three categories of Operational Transaction Errors (order processing, order fulfillment, and payment processing) are mostly outside of the direct control of the Collections department. Many times, organizations will develop cross-functional process teams to address these errors. While a good first step, these teams tend to perform static audits, create paper checklists, and manage backlog through spreadsheets.
What these teams have not achieved is systematic real-time visibility into these errors when they occur such that they can be resolved upstream in the process versus waiting thirty days past the due date. Specifically, of the 100 invoices that are sent to customers, if 20 have errors, then there needs to be a way to identify those 20 erroneous invoices (needle in haystack problem), and identify those errors in real-time when the error occurs. The following approach is suggested:
Quantify the Problem
Back to News