Balmori Software Inc.

[ Article ]

Photo: Museums Victoria

Today, we'd like to share a story that highlights one of the occupational hazards software designers face: the pressure exerted by customers to institutionalize (computerize) questionable practices.

A user of our SURE! AR/ AP/ DMS solution (a subsidiary ledger/MIS/logistics software) recently questioned what she considered a procedurally cumbersome aspect of the software.

Customer comment: When inputting sales transactions, the software should have provisions to distinguish between COD sales and credit sales. There should be a cash invoice for COD sales and a charge Invoice for credit sales.

Our considered response is: This complaint is interesting because it reveals a certain mental model among some bookkeepers and accountants. This in turn is the tip of a very large iceberg of hidden implications, assumptions, and behaviors.

(Please don't take what follows as an unasked-for seminar on basic accounting - not presuming to teach our grandmother how to suck eggs here. Rather, we'll use a widespread accounting practice to illustrate a common problem in Philippine SME businesses: the tendency to cling to obsolete processes.

And how clinging to obsolete processes can impede the SME's transition to computerization.)

Here's the deal. Thinking of cash sales as distinct from credit sales usually evolves as part of a short-cut technique for accountants operating in a manual accounting system. The point of the short-cut, and its perceived advantage, is that the sale and the collection can be booked in one single transaction entry.

But this only seems efficient. What happens when a customer makes a partial payment (or a down-payment)? Is this a cash sale or a credit sale? The answer is, of course, that it's a sale transaction for which there has been a partial collection.

Tossing in this common complication leads us to make a more basic and more useful distinction: a sale is one financial event; a collection is quite another. When you express it this way, you begin to see that it's not very rigorous to speak of credit sales vs. cash sales: because talking of "cash sales" just muddles the issue by combining the two financial events into one.

If you accept the model of distinguishing between a sale and a collection, you can see that there are advantages in treating all sales alike, and in not making a distinction between credit sales and cash sales.

The main thing to note instead is, all sales give rise to receivables; and receivables are extinguished by entering a collection transaction (or, less frequently, by making an adjusting entry, as appropriate). It's a simpler way of describing the the process. It's a simpler mental model. It's a truer model of how the world works.

Balmori Software adopts this architecture in the design of SURE! AR/ AP/ DMS. In this software, all sales - be they cash sales or credit sales - are recorded in just one Sales Book. Now, if a sale is immediately paid for on the spot ("cash sale"), it's easily handled by entering a collection transaction immediately. This extinguishes the receivable (AR/AP/DMS does this automatically). Therefore, all sales for which no collections have been encoded, by definition remain Accounts Receivable.

Some will jump on this and say this doubles the data-encoding work: the encoder inputs the sale, and then he has to input the collection - twice the work. And this, in fact, is the root of why some people choose to differentiate cash sales vs. credit sales in the first place: they're thinking they're eliminating a whole lot of inputting of collections by designating a class of sales as "cash sales." After all, who wants to input 200 or 2000 OR's, or even just 20, if you can possibly avoid it? If you don't look beneath the surface of things, this looks like a very sensible attitude to take. If you don't look beneath the surface.

Let's take a look at a couple of situations to see if this model holds up. What happens when a customer pays with one cheque for something he bought just this minute, as well as to make a final payment on something he purchased and made a down-payment on last week? So, you issue him one OR for this payment that covers two invoices. So now the question is, where does this transaction go? Does it go to cash sales, or to credit sales?

One response could be: oh, we'd put rare exceptions like this into cash sales, because part of it is in fact a cash sale transaction, while the other part is a cash settlement of an outstanding receivable. Great, but this means your cash sales register is now "tainted" with what is really a final collection on a credit sale. Where are your neat categories now?

And, by the way, how much time did you spend recording this "special case" that straddled two categories?

Another possible response might be: oh, no problem, we have a policy that we require a separate OR for the cash portion, and a separate OR for the credit portion. Even if you can say this with a straight face, you're now facing having to issue two OR's, which means you've just doubled the time you spend issuing OR's. So now you begin to see where the left hand is taking away what the right hand gives?

Or you could say, No, no, no, you've got a point there... OK, yah, we'll issue just one OR for every collection; except, yah, we'll have a policy that customers should pay via a separate cheque for each invoice. Again, assuming you're able to say this with a straight face, you're saying you're now willing to irritate your customers?

Therefore, isn't this beginning to look as if a short-cut that was developed for its seeming convenience... has given birth to its own inconveniences?

That's not even the half of it. What if your company has a bookkeeper in charge of recording sales, and a separate cashier for collections (a good practice, by the way)? Will Ms. Bookkeeper and Mr. Cashier have to powwow together every time a customer makes only a partial payment? Will they have to confer together to slice and dice the transaction every time a customer pays for two or three invoices with one cheque?

All of these real-world possibilities argue in favor of treating all sales alike, and then recording all collections as they come in, whether it's two seconds or two months after the sale. It just makes life simpler. As we find so often in life, doing things right the first time... is the biggest time saver of all.

Furthermore, it's not just about avoiding pain; the unified-sales approach, far from being a hardship, actually brings several powerful benefits to your day-to-day operations.

What are these benefits?
First, you get a convenient, unambiguous Sales total in one place. Your Sales Book becomes a true reflection of your total sales. You no longer need to keep track of a Credit Sales Register and a separate Cash Sales Register. This saves a lot of clerical time, because maintaining two registers surely takes more time than maintaining just one.

(Furthermore, keeping two registers doubles your chances of clerical errors. Enough said.)

Second, if you handle all sales in a uniform way, it becomes impossible to mistakenly record a credit sale as a cash sale, or vice-versa - with its attendant collection and reconciliation problems for your back-room. And as any office manager knows, a major cause of back-room inefficiency is re-work; so anything that eliminates re-work is a big cost-cutter and efficiency improver.

Third, what's even more pleasant is if the opposite occurs, and an already-collected payment on a cash sale is somehow neglected in inputting collections. Then it will appear (undeservedly) in the receivables. You will then try to collect; the customer will quickly rap your knuckles by citing you the OR that you already issued; and you will have a chance to correct your mistake - by the simple and painless expedient of inputting the aforementioned, inadvertently un-inputted collection. And note how in this situation, no reversing entries are necessary; all you have to do is do what you somehow neglected to do.

But the important thing to appreciate is that, fourth, with the unified-sales approach, your clerical/data- encoding mistakes will be in your favor; ie, it is more likely that you already have your customer's money, and he is explaining to you, rather than that you are having to explain and run after your customer for collections. This is a very practical advantage for the unified-sales approach.

Conclusion. Aside from the technical challenges of designing and programming complex code, software programmers constantly face the danger of giving in too readily to all the customer's requirements, even when these requirements are wrong-headed. And the pressure to give in is tough to resist. After all, "the customer is always right," yes? Or, how many times have we heard the platitude that "The customer should not have to adjust to the software; it's the software that should adjust to the customer!"

But all this glib flattery of customers is nothing more than salesman's sycophancy. In real life, it's false framing to express it as a matter of "the customer adapting to the software." In real life, the problem is that the customer typically has in place processes evolved in a noncomputerized environment, and he is now demanding that the programmer enshrine this exact same system in code, , even when these processes are clunky and inappropriate.

It's a question of the customer having to recognize that he needs to change his processes to attain better outcomes. If that's "the customer adapting to the software," then it's a good thing, not something to sneer at.

When the customer is bulling his way towards a wrong design direction, a good software designer/vendor will stand his ground and insist on adhering to basic principles. In this way, the software vendor protects the customer's true interests, and produces a robust, long-lasting solution that will truly accomplish the customer's business objectives.

Being complaisant in the name of "the customer is always right" has produced a lot of garbage software. It's the mark of beginner programmers and amateur programmers.

We hope this article will help you extract more value out of your SURE! AR/ AP/ DMS, and perhaps contribute constructively to any ongoing debates in your company about implementation approaches. And if you're just now embarking on a computerization project for your company, perhaps this article will help you avoid a not-so-obvious, but very deep, pitfall.

Our little anecdote is just one example of how clinging to old, accustomed practices can derail a computerization effort. Especially if these practices come from a manual system, where it's accepted that processes take time to complete. You don't need to be experienced in implementing computerization projects to see that time slack can hide a a lot of poor processes.

A good rule of thumb is, be skeptical of procedures developed in a manual regime. They often hide inefficiencies that have gone undetected because of lax deadlines and insufficient attention to interactions with other departments in the company.

A computerization effort is an opportunity to expose these inefficiencies, and to - let's finally use the word - re-engineer your egregious processes. In this quest, a favorite quote from inspirational speakers all over the world comes to mind: "If you want to change your outcomes, you must first change your behaviors."

Or to put it a little less politely: "The mark of insanity is to do the same thing over and over again, and yet to expect a different result." rsr/rcd



Title:   Are your current processes hurting your effectiveness?
            Cherished practices are not always the best practices



Share on

                                                                

<<< Back to top >>>