BSI Red Logo Balmori Software Inc.

We make it simple.


[ Article ]


Share on


FB

Twitter

GooglePlus

Mail

Mail           

1910-1b

How to foolproof your handling of PDCs
If your company is using an enterprise software solution of any sort, you've likely encountered this issue regarding postdated cheques


Progressive-minded companies nowadays tend to run ERP software (Enterprise Resource Planning). This is an integrated back-room system that acts as a "single source of truth" to enable operating and staff people to do their jobs faster and more accurately, from purchasing to inventory control to billing and collections. SURE! AR/AP/DMS is just such an enterprise solution that handles the entire back-room of a company. It acts as a central nervous system which contains data on all company transactions, and produces hundreds of synchronized, mutually consistent MIS reports.

A user of this powerful ERP solution recently raised the following criticism regarding the way the software handles postdated cheques:

The computer cannot substitute for certain things we need to do in the physical world

PDC's should not be automatically taken off from customers' AR-Trade balance/suppliers' AP-Trade balance. They must only be recognized upon due date so as to avoid making adjustments every month-end for all the PDC's of the month.

A number of our clients using our SURE! AR/AP/DMS enterprise solution have raised this very point over the years. And they are all correct.

The logic, not only of SURE! AR/AP/DMS but of mainstream accounting practice, is that once a collection has been finalized/posted, then by definition (i) the receivable is extinguished, (ii) the customer ledger is updated, and (iii) the collection book is updated.

Therefore, when you finalize a collection within SURE! AR/AP/DMS, all these three things happen automatically.

These financial events move together in lockstep, whether you are talking of a computerized or manual system; they are inescapable, whether you are talking of a computerized or manual system. (For this analysis, we confine ourselves to collection transactions, but everything we say here applies analogously also to disbursements and to A/Ps.)

1908-1c Now, if you are dealing with a PDC, as opposed to a value-dated (or matured) cheque, then your basic reality, in stark terms, is that you have a piece of paper in your hand (the PDC), but it's not worth anything yet.

If you look at it in these down-to-earth terms, then the problem becomes very clear: Strictly speaking the details of the collection should not be inputted-then-finalized/posted in SURE! AR/AP/DMS until the value date comes around. Because strictly speaking, as long as the value date hasn't arrived yet, you have not yet performed a collection. That financial event hasn't occurred yet. So there is no justification for posting the collection until the value date comes around.

We know what you're thinking (because this point has been thrown at us by dozens of users over the past 30-plus years): I should be able to input-and-post the PDC, but the software should only update the associated subsidiary ledgers when the value date arrives.

Here we must confront one basic reality: there are certain things that need to be done in the physical world that the computer cannot do. In the computer, we can only go as far as to input the details of a PDC; but we still need to do several things in the physical realm, things that no computer can do:

(i) because we cannot deposit the PDC until a certain future date - ie, its maturity date - we must "warehouse" all PDCs, in a physical storage place somewhere in our office, and do it in a systematic way in order that we can retrieve them on value date for deposit to the bank.

(Being computerized does not make this reality go away. Even modifying the software, as described, would not make this reality go away.)

(ii) on the arrival of its value date, we must actually retrieve the PDC from its storage place, and deposit the cheque in the bank. (Being computerized - or modifying the software - does not make this reality go away.)

(iii) on arrival of value date, this is the time to prepare and issue an Official Receipt (OR).

(iv) the existence of the OR is the proper trigger for finalizing (posting) the collection transaction in the software.

Software solutions that deliver. No excuses.



Easy-to-use, reliable solutions that work from Day 1.
Since 1985

BSI Bear Anvil



(v) the finalizing (posting) of the collection transaction is, properly, the final act that updates the associated subsidiary ledgers (eradication of the receivable, updating of the collections report, and updating of the customer's ledger).

As earlier stated, SURE! AR/AP/DMS executes this automatically when you post the collection.

Therefore, to want to "input-and-post the PDC but to require the computer not to update the associated subsidiary ledgers until value date" is irrelevant to the true situation.

Even if you had this wish-item, having it would still not relieve you of having to physically warehouse the PDCs in an orderly manner; it would still not relieve you of having to dig out the PDC on value date, deposit it in your bank, and get a deposit slip. It would still not relieve you of having to prepare an OR for the payor.

Redesigning the software so that it will "input-and-post the PDC but not update the associated subsidiary ledgers until value date" is a meaningless alteration of the software's capability, because the important things are the actions that you still need to perform in the physical world (ie, items (i) through (iv) above).

Therefore, when all is said and done, having the above-alluded-to wish-item is not the solution. The solution is to have a solid, robust system (ie, process) of physically warehousing the PDCs, of ensuring that somebody determines daily what PDCs are maturing, of ensuring that the cheques are reliably deposited on their maturity (value) date, and of ensuring that payors whose PDCs have matured get issued their OR's. There are some actions that have to be performed outside the computer; this is one of them. - rsr



Did this article resonate with you in any way? Click here to respond to the author. Or click here to ask for a return call by one of our officers to discuss your concerns. Or you may simply email us at balmori@balmorisoftware.com.


Share on

               FB          Twitter          GooglePlus          Mail          Mail         



Questions? Reactions? Write to balmori@balmorisoftware.com.




<<< Back to top >>>