[gnue-sb-discuss] Purchase Orders for Utilities, etc.

[Peter Sullivan]

Picking up on a conversation from IRC yesterday...

Actually, there is a good case for making people raise Purchase 
Orders (either call-off/blanket POs in advance, or specific POs 
retrospectively) even for things like utilities and rent. It has 
nothing to do with the system per se, but reflects the fact that 
systems get used by people (i.e. fallible human beings). 

If you have a business process where some AP invoices need to be
matched to POs, and some where the AP invoice is input direct, 
then you create a "corridor of uncertainty"* within the minds 
of your AP input clerks, and the scope for them to get things 
wrong. At its worst, this may result in them doing just the 
most perfunctory of checks for a matching PO, before concluding 
that "this must be an invoice that doesn't *need* a PO" despite 
clear external evidence to the contrary (e.g. description of 
goods as clearly PO-able). So they input it as a direct AP 
invoice, rather than matching it to a PO.

This then means that the commitment record in the General Ledger
(for Orders Raised Not Received) never clears, which the 
budget manager for that cost centre may or may not notice, 
depending how keen they are on commitment accounting anyway. 
Multiply this over time by hundreds or thousands of POs, and 
you have an out-of-control situation.

This is not just a theoretical problem. I spent quite a bit of 
time with at least two clients of my last employer trying to 
unpick this, and one of them eventually had to write off all 
outstanding POs more than six months old, on the grounds that 
they "must have been delivered, but the invoice input wrong."
And when we were doing site visits for the ERP system we are 
implementing at my current job, one of our reference sites 
had exactly the same problem. (I deliberately haven't named 
either system, as it's not the fault of either system.)

By insisting that every AP must have a PO, you force people to 
do sensible checks before firing the invoice back to the 
originator and asking why a PO wasn't done for it. (Depending 
on your company procedures, there may be varying degrees of 
"acceptable excuse" here.) Ending up with 'non-intuitive' 
POs for things like Utilities and Rents is the lesser evil 
here.

The other alternative, I suppose, is to put some intelligence 
into the system, so that each account code within General 
Ledger has a flag on it that says whether a PO is required 
for AP invoices to that code. If the flag was set, which 
should probably be the default, the system would refuse to 
allow a direct-input AP invoice to cost there, but would 
require it to be matched to a PO instead. If the flag was 
not set (for example, on Payroll, Utilities and Rents codes)
then direct input AP invoices would be OK. Having said this, 
I am not aware of any system that does this as of time of 
writing, so I wonder if there is an obvious flaw with this 
that I've not spotted.

-------------------------------------------------------------

* My apologies to Geoffrey Boycott (now *there's* a phrase I 
never thought I'd type) for (ab)using his cricket-related 
metaphor.
-- 
Peter Sullivan