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
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
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 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.
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
(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.
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
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