Cash Flow and Strategic Partnering: Understanding What You Don't Control

©2002 Business Credit Magazine
By Alan Mitchell
October 2002



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
· Order Processing
· Order Fulfillment
· Payment Processing

THE COMMON ISSUES IN OPERATIONAL INTEGRATION

Order Processing

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.
In some instances, the product may have already shipped, in which case order administration may raise a RMA and re-create a new sales order. In other scenarios a duplicate sales order may be created.

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 rule.
Unfortunately, due to recurring changes in the requirements of strategic customers, it is difficult to maintain an updated set of rules without dedicated resourcing from IT. Also, oftentimes the complexity of the rules are such that they can not be replicated in the systems environment.

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.
Also, a high degree of difficulty exists in maintaining a dynamic set of customer specific business rules that are subject to frequent change. For example, pricing structures are usually customer specific but also change on a quarterly basis.

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

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.
Two elements of the process typically result in invoicing discrepancies:

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.

Payment Processing

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.
Automated lockboxes may achieve 90% plus accuracy, but if the remaining unapplied or unidentified receipts are not resolved, collectors end up devoting their time to reconciling accounts or worse yet, making collection calls on paid invoices.

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 Identification: Very seldom are the root causes accurately identified, either because the majority of disputes are captured under a 'miscellaneous' reason code or because the dispute reason is incorrectly interpreted by the collector. But most often the dispute reason does not identify the root cause, only the symptom identified by the customers accounts payable department.

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.

Solutions

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
Perform a rigorous analysis, including data sampling, to quantify the magnitude, frequency, and specific root causes of the Operational Transaction Errors.

Implement a Software Solution
Implement a software solution that captures information from the disparate systems, correlates the transactions, performs reconciliation algorithms and applies business rules to proactively identify the Operational Transaction Errors, and finally exposes them to all of the relevant parties (order processors, order fulfillers, and payment processors) early in the quote to cash cycle - the algorithms and business rules identify the 20 out of 100 errors - solve the needle in haystack problem - early rather then when its too late. You want to maximize flexibility in your software solution, such that you can accommodate new rules as business processes, root causes of errors, and customer behavior inevitably changes.


The solution is effectively mimicking the accounts payable process of your customers that are performing a two-way or three-way match to determine if an invoice is acceptable or rejectable. Once you are able to model your customer's business process within your business, then you are able to identify possible disputed invoices before the invoice is even generated. And the result of this is reduced DSO, reduced order cycle times, and reduced rework.


  Back to News