In this edition of "Whiteboard Breakdown", I walk through a Disputed Deduction workflow, which is a may seem a little atypical as part of the Q2C process mapping and control discussion; but I feel it’s necessary. As I point out, it’s crucial to recognize, document and standardize those procedures that occur irregularly and usually in response to an undesired customer action, here in the form of a deduction on an invoice. I mention this specific process, as it relates heavily to the topic at hand.
Too often we only focus on those measures or dimensions of data in which we are concerned with, both during operational and financial reporting. We pull a dataset based on what we think we know about the data, and often, especially when dealing with customer payment adjudication data, ten to twenty fields are left unutilized or not considered. Customer and dollars, contract and dollars, product and dollars…this is what we look at most often. Without a complete understanding of all of the data elements that associate to these reported or pulled lines that we are focusing on, a true understanding of the data itself may be lacking. And in turn, your reporting of the data could be inaccurate or misrepresented.
It is also not only in reporting figures that certain measures of data are overlooked. It’s also in the processing or validating of data, during the actual operations utilizing this data, that oversight could be detrimental. We see this most often in the first measure discussed.
Units first become a problem during operations and then often later affect reporting; and the type of reporting I’m really speaking to is Government Pricing reporting. This specific measure speaks right to the Disputed Deduction process, as this is an easy place to misrepresent units. For example, a customer takes a deduction on a sales invoice for an overdue rebate. This deduction sits on the customer account for some time before brought to the attention of Finance (and maybe Sales and Marketing). At some point, a decision is typically made, usually based on materiality and maybe aging, to settle the dispute through a re-process or even a write-off. The issue lies in the lack of support detail for the rebate payment itself. Nothing can be found in your system or files, and the customer is not required to re-submit detail after a certain period of time. Therefore, that certain GTN rebate balance sheet account is hit for a certain dollar amount…and ONE UNIT.
Customer’s paid, A/R account is cleaned up; everyone is happy….right? For now, perhaps yes. But what sales operations and finance folks might not consider, is the effect this manipulation of units has on the PUR (per unit rebate) calculation that occurs later downstream for GP. Now, you have a PUR that is misrepresented and will go on to potentially misconstrue certain GP calculations; those same calculations that carry big legal action and fines with the misrepresentation of. Listening now?
Earned Period (Invoice Date)
We see a very similar and just as frequent disregard for Earned Period during the Disputed Deduction process, as we do for Units. A customer tells us we owe them for an overdue rebate for a certain dollar amount, yet it was earned too far back to provide any detail; therefore, we process the credit without the appropriate earned period.
Problem is, you either did or did not accrue for this liability at some point in the past. You potentially have accrued dollars still on your books associated with that earned period, and without the proper earned period data on the actual payment data, you will never be able to match them up and close out that given liability period. Or, maybe you truly never accrued for this liability. It will then, since being paid in the current period, misrepresent your true favorability on the current reporting period; potentially showing that your reserves were sub-par for this period.
Ensuring that you properly assign and report on Earned Period, will help you keep your GTN liabilities, both current and past/aging, at least straight on your reserve analysis and financial reports. From there, you can begin to build a reserve methodology for these ‘unforeseen items.’
Paid Period (GL Posting Date)
While on the topic of date as a data dimension, I’ll mention Paid Period as well. In my experience, the issues surrounding paid period occur more often with pulling or reporting on actuals data for purposes of forecasting or discount projections. The problem usually begins, in that the reconciliation or tying out of actuals data is combined in process with pulling data for projections. The data is not always spun both ways: by earned period AND paid period. If data is only pulled one way, it may not reconcile to the GL. If it is only pulled the other way, payments may be missed due to timing or even just the parameter dates selected.
It’s always important to analyze your customer payment adjudication data by both sets of date, to ensure, 1) complete understanding of the data set, and 2) ensure you are using the correct and complete set of the data to the applicable downstream process.