The buyer PIN problem

Ask anyone running a busy counter what goes wrong with invoicing and you will eventually get to the same story. A customer buying for a company wants an invoice made out to the business. That invoice needs the buyer's PIN. The buyer does not have it to hand, or reads it off a phone screen incorrectly, or the cashier types it while watching the queue. The sale completes. The invoice does not, or it does and it is wrong. This gets treated as a software problem. It is not. It is a twenty-second problem at a counter, and the fixes that work are counter fixes.

Why reconstruction does not happen

The standard fallback is to capture the sale now and add the buyer details later. In practice "later" means someone going back through a day of transactions trying to work out which of them was the company purchase, asking a customer who has left for a number they did not have then either. It very rarely happens. Not because anyone is careless, but because the information was easiest to get at the exact moment it was needed and is progressively harder every hour afterwards. Any process that depends on going back is a process that depends on the least likely thing.

The businesses that solve it

The ones that handle this well do something unglamorous: they ask regular business customers for the PIN once, keep it, and stop asking. A wholesaler with forty trade customers does not need to capture forty PINs at forty tills forty times a week. It needs to capture each one once and recognise the customer afterwards. That turns an interruption into a lookup. It also removes the transcription risk, because the number is typed carefully once by someone who was not being watched, rather than hurriedly every time.

What to check when one is refused

When an invoice comes back rejected and the buyer's PIN is the suspect, check it against something the buyer gave you rather than against what was typed. Read it back digit by digit; a transposed pair is invisible to the person who already knows what it is supposed to say. And establish whether it is the PIN of the entity actually buying, because a person buying for a company they own will often give you the one they think of as theirs. What the specific rejection means is KRA's to say. But in our experience of how counters work, the order to check is: right number, right entity, typed correctly. Most of them are in that list.

The wider point

A lot of eTIMS difficulty is described as technical and is actually operational. The system is asking for information the business has, at a moment when the business is not set up to provide it. Fixing the counter is usually cheaper than fixing the software, and it is almost always faster.