[OpenSpending] Follow-up to transaction standard call

Sat Oct 20 15:05:52 UTC 2012

I know I am joining the discussion late after not following it closely, 
but this reminds me of some questions we struggled with a couple of years 
ago when we first got our hands on COINS.

I remember that a big obstacle to getting things from the data was that 
various government organisations paid each other to do things, so that the 
same money showed up multiple times. This was particularly true within the 
NHS. It makes it very difficult to get accurate totals. To avoid this 
problem, I think we would need:

  - Transaction-level data.

  - Useful data about the recipients of payments, by which I mean that it 
should be possible to see if the recipient is another government 
organisation, and if so which one.

I worry that contract-level data would miss a lot of interesting 
information. Payroll, for example. Also cost overruns, non-performance, 
disputes, and mismanagement would show up in transaction-level data but 
not in contract-level data. Many procurement decisions look sensible on 
paper...

I can see that contract-level data would also add lots of new useful 
information about the purpose of the transactions. I don't think either of 
transaction-level data and contract-level data really replaces the other.

Bulk of data is not in itself an insurmountable problem. We have computers 
and dedicated people. Given ledger-level transaction data the task of 
reducing it is manageable, provided the books balance. However, if you get 
a dumbed-down version of the data that has been processed and reduced and 
summarised so that it no longer balances, then you don't really have 
anything at all.

Sorry if I have missed the point.

 	Alistair

On Sat, 20 Oct 2012, Lucy Chambers wrote:

> Hi James, 
> Thank you very much for writing this all up, I think that it is worth circulating it straight away to the list in order to get their thoughts. 
> 
> @all - James McKinney has taken the time to run the proposal for a spending standard as discussed on the last community call by an accountant. He raises some
> concerns about whether the focus of our current efforts should in fact be a standard for transactions, or to actually focus on the contracts as the most interesting
> source of information. 
> 
> James, I also agree with you that it is worth looking into the SAP, Oracle etc guidelines on this information. I am led to believe that  the majority of the world's
> governments actually use software from a very small number of providers. 
> 
> In order to help shape the discussion further, it would be useful to know from those on the list: 
> 
> * What questions would you need to be able to answer using transaction-level spending data?
> 
> I am currently writing up meeting notes and am prepared to organise another call soon if people feel this would be helpful. Let's consider James' points and I will
> proceed accordingly, 
> 
> Thoughts?
> 
> Lucy 
> 
> 
> 
> On Friday, October 19, 2012, James McKinney wrote:
>       Hi Lucy,
>
>       Feel free to forward to openspending list if appropriate.
>
>       I asked an accountant for feedback on the standard. She has not worked for government. Two big questions were:
>
>       1. Do you already have data that you want to represent using this standard?
>       2. What are the use cases and requirements for this standard?
>
>       The high-level process in government (and in many corporations) is for example:
>
>       A budget for office supplies is set to $10,000.
>       Purchase orders are made throughout the year, eg a purchase order is made to buy $1,000 of paper.
>       Processing the purchase order creates a commitment, so that only $9,000 of the budget is considered available.
>
>       The commitment can then:
>       1) be cancelled
>       2) be relieved when the paper is received
>       3) the actual cost is lower than the commitment, so the difference is uncommitted
>       4) the actual cost exceeds the commitment, in which case authorization must be given to increase the commitment from the same budget or another budget
>
>       Searching these keywords brings you fascinating documentation like Oracle's JD Edwards EnterpriseOne's chapter on "Processing Purchase Order
>       Commitments".
>
>       A few things come out of even just this simple explanation:
>
>       1) If you want data at this low level, then you are signing yourself up to create your own government-scale accounting system, which is a Herculean
>       effort. Will you be modelling all the back and forth that occurs when the commitment must be changed? In accounting systems, changes are considered
>       transactions. The current standard has no concept of ledgers, so I assume you (wisely) will not go in this direction.
>
>       2) The current transactions.txt has amount_budgeted, amount_allocated, amount_executed, but it rarely works that way. Organizational units (eg
>       departments) don't create a budget for each purchase of office supplies. A unit would have one budget for office supplies, which multiple transactions
>       deplete.
>
>       3) In an accounting system, there will be no difference between the amount allocated and the amount executed. You can't balance the books if it's
>       otherwise! In all cases, there would be a transaction to change the amount committed (allocated) to match the amount that must be paid (executed).
>
>       On the call, one justification that I remember for having both fields is, for example, if a contractor doesn't cash a cheque. But in that case, the
>       money doesn't get recycled - it stays in Accounts Payable. Accounting systems rarely care when cheques are actually cashed. If money is in Accounts
>       Payable, then in the government's view *it's no longer its money.*
>
>       Clarifications:
>
>       In a call for tender for paving a specific road, the government would estimate the cost, and contractors would submit bids which will differ from the
>       estimate. The government estimate wouldn't be amount_budgeted, it would be amount_estimated. The money for the contract would come from a larger "road
>       work" budget.
>
>       If we look at USAspending.gov, those aren't transactions, they're contracts. There will be many transactions tied to a single contract. But do you care
>       about all the component transactions, or do you care about the contract as the basic unit of interest? If so, then this project should focus on
>       contracts, not transactions.
>
>       If the focus really is on transactions, then I would study the documentation that SAP, Oracle and others have for their government-focused accounting
>       products. (Of course, most governments rely on ancient custom-made DOS programs and the like.)
>
>       Use cases:
>
>       I think a good use case is the comparison between budgeted and actual spending. You don't need to go as low-level as transactions to do this, though.
>
>       Last note:
>
>       It might actually be very easy to model transactions. But what you get for modelling transactions is probably not what you want. A transaction is a
>       transfer of money between two accounts - but a lot of the time both accounts will belong to the government! I don't think people want a long list of
>       transactions leading up to each transfer of money to a third-party. And I don't think people want each transfer of money made to a third-party as part
>       of the same contract. Am I right? If so, transaction-level spending is not the right focus.
>
>       Looking forward to your thoughts,
>
>       James
> 
> 
> 
> --
> Lucy Chambers 
> Project Coordinator, School of Data & OpenSpending
> Open Knowledge Foundation 
> Skype: lucyfediachambers
> Twitter: @lucyfedia
> 
> 
>