-
data.gov.uk – Local Data – Payment Publishing Response
7
June 2nd, 2010Public DataThis is my response to Publishing Itemised Local Authority Expenditure Advice, unfortunately the captcha appears to be broken when I attempted to post this.
These are just my personal thoughts, and may be incorrect, and they do not represent the thoughts of my employer.
Supplier Identification
I disagree with the phrase ‘Ideally publication would include the Companies House number (or equivalent in the case of foreign companies) or Charity registration number‘. This depends on the quality of data entered into the system, in my experience such level of detail (at least for private sector companies) is never recorded in a Supplier master. You will have the Supplier Name, Internal Supplier ID, Address fields, basic contact details (with a CRM system likely to be holding more details).Such information is not easy to populate into a system if it’s not already present, I remember a case where we had to identify Dun&Bradstreet numbers for every supplier – it wasn’t an easy job.
I would say, this boils down to one thing – why do you require that level of information, what is wrong with the company name after all unless we are talking about data quality issues?
I’d also be wary of needing to publish the actual contact details for each company, depending how a companies supplier master is setup, you may have the contact details for the person in Accounts Payable. What use is that to the end user? It would need to be researched to understand exactly what data is present etc.
Payroll/Benefits
Dependent on how the Supplier master is setup, it is possible for employee expense reimbursements to be present (i.e every employee is setup as a vendor). Most systems allow you to identify these, not all do though. So it may be possible to anonymise these.Payroll, at the General Ledger level is likely to be a few entries (the transactions hitting the GL Payroll account, and the bank account), the Payroll data of actual payments (BACS likely) may be held separately to that of where normal supplier payments are made (again, dependent on system structure – I’ve seen them a few ways).
Overall
The other thing to remember, is that in some cases, the data output is likely to be:01/01/2010
CHQ
£2256.89
A1 Company
INVXYZ002 (or some document reference)
GL CODE
GL Description (i.e Transportation)
Cost Centre Code
Cost Centre (Parks Department).The above shows that the Parks department paid A1 Company, £2256.89 on -01/01/2010, for a service that the invoice was booked to transportation, and the cost absorbed through the parks department budget.
You’d be surprised how many times there are some systems where it’s not totally easily to identify the payment, back to the relevant invoice (apart from a manual reconciliation), you need to know the invoice side of the transactions – as that is where the cost will be booked to (as the payment details will just be crediting cash, debiting Accounts Payable).
It all depends what level of detail you want to show, it’s easy enough to show a payment went out (but associated services, dependent on the internal reporting functions of the system – may be harder).
These are just my thoughts, from my experiences of working with a multitude of different financial systems from your SAP, to your BAAN and SunSystem.
Tags: accounting, council, council expense, data.gov.uk, hyperlocal, local data, payment publishing
7 Responses to “data.gov.uk – Local Data – Payment Publishing Response”
-
Really useful post. My experience of accoutns systems at private sector companies is also that Companies House numbers are rarely stored. However, it’s precisely for this reason that we need as much information about the supplier — the name entered will be fairly arbitrary, and may not be of the company but of the division or the trading name.
Matching this up across different bodies will be pretty difficult, to say the least. However, if we’ve got the address, VAT number, or even domain of the email address, it starts to become a lot more feasible, even if it’s not easy and may require some help from the crowd.
Re the date, I’m wondering if we need all associated dates. The systems I’ve worked with (Sun a long time ago) would from memory have had three dates — the invoice date, the payment date and I think also the period (usually month) it was allocated to.
-
[...] open standards. Help Me Investigate contributor and all-round good guy Neil Houston has already responded with some very interesting points. "You’d be surprised how many times there are some systems [...]
-
Neil H
Agree there countculture.
Again it depends on the aim, is it for the councils to do such work, after all they fufil their obligation. The fact that people may want to cross link systems is not their remit.
Again from experience the name information in a supplier master is likely to have data quality issues, as well as duplicates etc.
Regarding dates, most systems have quite a few: date of invoice, date invoice posted to GL, date of payment, date payment posted to GL etc etc.
Also technically you might want to consider what happens regarding part payments of invoices, or consolidation of invoices (i.e 10 invoices for £50, get batched into one payment of £500 etc).
-
[...] Data & Stuff » Blog Archive » data.gov.uk – local data – payment publishing response (tags: neilhouston rasga data councils) [...]
-
[...] Last week I commented on the proposal that councils would have to publish their payments made to suppliers that were over £500. You can see my full thoughts, here – Local Data – Payment Publishing Response. [...]
-
[...] bigger problem, as I’ve said before, is being able to identify the suppliers, and this becomes particularly acute when you want to [...]
-
I think I’ve hardened my position a little of identifying suppliers, after having started importing the data into OpenlyLocal, and thus faced some real-world (as opposed to theoretical) probs.
From your more recent post, you seem to be coming around the idea that using just the name of the supplier (which may not be the Company name) is problematic. By blog post re this is here.
