17 Jul 2016 P.O. Flip is Flipping Flawed
I’m fortunate. Like most people, I’ve never been in a serious car accident but accidents do happen and seat belts save lives. I must have been on tens of thousands of car journeys and despite the fact that I’d be no worse off if I’d never worn a seat belt, I still do and always will. So when a software provider says in answer to the question “What if something goes wrong?” and they say “But it shouldn’t” you have to question their judgement.
This kind of muddled thinking often happens when non-procurement people get involved in contract negotiations. They use the contract to describe what is supposed to happen – supplier provides a service, buyer pays – but they don’t pay enough attention to the bit about “what if something goes wrong?”
I’m reminded of this when P2P vendors talk about P.O. flip. For those unfamiliar with P.O. flip, it is a means of creating a digital invoice from a digital P.O. If I am a buyer and I create a purchase order from an online catalogue, it is reasonable to assume that the invoice information will reflect very closely what the P.O. information contained. It is possible therefore to effectively use the same information and “flip” the P.O. data to create an invoice. In this way, the invoice and the P.O. will always match.
Auditors will see the flaw in this logic straight away. The assumption is that the P.O. is correct all of the time. There’s also an assumption that the full content of the P.O. is shipped by the supplier. But “there’s many a slip twixt cup and lip” as they say – which roughly translates to “there’s a lot that can go wrong”.
P.O. flip has its place. There are some categories of spend and some P.O. scenarios where the invoice is almost by definition going to be identical to the P.O. Corporate software licenses for example. There’s a catalogue of one product – a new user licence. There’s no delivery charge, no variance from one user to another – that works well. But, apart from simplistic purchase to pay situations, P.O. flip is flipping flawed because it has at its heart an assumption that things always happen the way they should.
When you say to a software supplier – “but what happens if things go wrong?” – the answer should not be “well it shouldn’t”. We know it shouldn’t – like I shouldn’t crash my car. But what if I do?
Procurement and P2P systems are supposed to automate P2P processes but if they focus only on simplistic scenarios or have at their core an assumption that things always happen as they should, they add little value because in the real world, you’d not be automating enough to deliver efficiency. P.O. flip isn’t enough.
Pete Loughlin can be found on twitter @peteloughlin
