Report from the Trenches
Cobudget is a tool for collaborative money allocation that came out of Enspiral. It started as a spreadsheet, then became a software tool, and has now been in use for several years in various forms. An entirely new version was written from the group up about a year ago. The idea of reclaming our money flows is compelling, and there is excitement from other progressive groups who would like to implement these tools.
This is a very nitty gritty report from about a year of operationalizing our use of Cobudget, based on experience and common patterns within the Embassy Network, Ouishare and Enspiral. Hopefully it can help groups who want to be early adopters (which helps us improve these tools and the processes around them), and give others a sense of where we are in the development process.
New infrastructure is Hard. All the groups mentioned here have invested countless hours working on and advocating for Cobudget. This discussion is not at all an attempt to dissuade from these efforts– quite the contrary, we’re all die hard about experimentation– but to take stock so we can continue to iterate and facilitate people adopting new ways of working together.
The basic concepts in Cobudget are groups, users and buckets. A group is a collection of people who are funding things together. A user is an entity with a balance in the system, and buckets are the conceptual container for project proposals (you “throw money into the bucket” is a metaphor for contributing).
The basic idea is that anyone can propose a bucket, and anyone can fund any bucket, creating a direct democratic flow of money between people and the projects they value.
In terms of operationalizing, it’s all about managing balances - how to how to move money into and out of cobudget while maintaining balances accurately, and how to manage payouts.
The key challenges we faced were: * No syncing with accounting software (most of us use Xero) * No transaction history on users or buckets. * No birds eye view of a user’s contributions across all buckets * No ability to see total money “in the system” * No payout mechanism for managing payouts of completed buckets
There are two main uses we have seen in these organizations and heard from others. One is one-off uses (eg. there is a chunk of money left over from a large project, like the Ouishare Festival, where the decision is to cobudget that surplus with a fixed group of people). In this case, you are less likely to need to add new allocations users, but total balance still needs to be stewarded, and payouts need to be managed.
The other is a recurring use case, as we have in Enspiral and Embassy Network. In this case, there is the added complexity of regularly appending new balances, as discussed below.
One off uses
When a user funds a bucket, the balance is removed from their account and added to the bucket. The “total funds” showing goes down (because less are available) but the total balance across all pots of money (users and buckets) is the same. This means you still need to hold the same balance in your bank account, but there is no way to see what that balance should be.
To calculate it, one has to click through each bucket page and look at the total amount allocated, and add it to the available funds.
Since there is no reconciling or payout mechanism, there is also no way to know whether a funded bucket has been paid out or not (and thus whether to you should include its balance in your expected bank balance). So, we need to manually note each time a bucket is paid out. Depending on how you are managing those payouts, the amount might also not be precise (eg. if someone invoices you and they spent $37.53 instead of $40).
If you need to audit the balance of user funds across all buckets (available, allocated by unpaid, or allocated and paid out), you must also manually click through all buckets, which quickly becomes impractical with many users.
In the case of Embassy Network and Enspiral, for most users it’s important that we track the total amount allocated on a per user level, because it’s money we consider that we ultimately owe these individuals (that is, it’s a liability– see below). Of course it’s also one more place for user error: if you enter one thing in a spreadsheet and one thing into cobudget, you’re out of luck.
If you intend to use cobudget on a regular basis, you have to do all this (correctly) for each new set of allocations, and there is room for human error at every step: move money into a bank account, bookkeep it appropriately in your accounting software, and make sure the amounts added tally up appropriately.
The primary concepts (groups, buckets, users) in cobudget don’t expose any history. Perhaps you make a calculation error and need to fix something. If you make a mistake at any step, there isn’t a way to know where that error was introduced, or thus how to correct it, even if you do notice it at some future point. So one you add balance to a user, you can’t go back and verify it was done correctly. Ever.
Off-boarding users is a task which arises periodically. In order to reconcile the accounts, one has to check through each funding bucket manually and total the amount that will be evaporated when their user account goes away (or is set to 0).
Similarly, if a bucket owner declines allocated funds for any reason, those funds have to be manually re-allocated to the users’ accounts.
Finally, the system suppresses decimal places and rounds down to the nearest whole dollar, which makes all the above accounting truly hair pulling.
Bonus: try onboarding your bookkeeper to all this madness!
Current management schemes
Here’s the key tools these groups have used to manage thus far.
- Use of a dedicated bank account
- Use of “virtual accounts”
- Spreadsheets to create plumbing between chart of accounts and cobudget
Bank account: Arguably more work and technically not necessary. Personally, I’m hyper anal about making sure we sequester any balances we’ve promised to other people, so that it could never be accidentally taken as general operating money. This means we have one more set of transfers and balances each time we do an allocation, but, honestly, it’s the least of the hassles given everything else, and provides peace of mind.
Both Enspiral and Embassy Network make use of internal “virtual accounts” to track how much has been allocated to specific users. A virtual account is basically a set of money set aside for an individual but kept in the organization’s bank account.
Embassy Network doesn’t have a “my.enspiral” (alas!), but we use Xero, which lets us track balances in similar ways (without the amazing sugar coating of allowing users to control those balances, or all the other cool things a tool like my.enspiral does).
For each of our key users we create a new account in our chart of accounts, of type “liability,” called “So-and-so’s virtual account”. We have about 20 of these, and each of them represents a balance that we effectively keeping in our bank account for that user, ie, we owe them that money eventually, so it’s a liability.
When we assess that we made enough money in a given month to issue community dividends, we create a manual journal entry to move money from an expense account called “community dividends” (which shows up nicely on our P&L as an expense for that month) to each user’s virtual account, with line items for each individual. So instead of actually paying these dividends, we record them as increases to the balance of the user’s liability account, ie, an increase in what we owe them. Then we copy those balances to cobudget, and we’re ready to go.
Our community knows that Xero is the ultimate arbiter of truth in the Embassy financial world, and if there is a discrepancy between Cobudget and Xero, it’s Xero which will be considered authoritative.
After any allocation of cobudget funds, we always double check that the total across all liability accounts is less than or equal to the balance in our cobudget bank account. This way, even if we forgot to reconcile something from cobudget, we’re secure in the knowledge that we have the funds to back what Xero says we owe our users.
Each organization independently designed spreadsheets that look roughly the same: they track money in and money out. With money in, they store a transaction log of money that was added to the cobudget group, by whom, to which user, the date, and any other relevant metadata for the org. For Embassy, we use a separate spreadsheet tab for each month, because we have long allocation lists.
With money out, there is a record of each bucket that was funded, the amount, who it went to, how it is accounted for internally, and the current payout status.
Notably outside scope of this discussion:
- There has been a lot of interest in linking cobudget to, eg., groups who have Patreon contributions set up, but any group doing this still needs to have their own banking infrastructure.
- Contributing funds to a group or project - there is no crowdfunding functionality. Cobudget doesn’t hold any funds.
- Lots of bookkeeping and tax implication questions - managing balances as liabilities might not be the right thing for your org. It also might be a bucket-by-bucket kind of thing. This will have implications for taxation, charitable contributions, etc. For example, a bucket where a user simply withdraws their balance for personal use, which we allow at Embassy Network, will be taxable as income for the user. And cobudget allocations that are recognized as profit and then treated as dividends will have different tax implications to something that is treated as an expense (for the organization and the user). Although cobudget doesn’t hold the money, mechanisms to tag buckets for different taxable purposes will facilitate peace of mind.
- In the same way that [Loomio] doesn’t replace person to person conversations, neither does Cobudget. Add to that, that cobudgeting as an activity is not familiar behaviour, so uncertainty about norms, permission and expectations will hinder engagement if not addressed. Don’t expect to put money in accounts and have magic happen. It takes a lot of time invested in facilitation for this to work.
Proposed developments to address these issues
- User balances and buckets need to be real accounts with transaction history. Double entry accounting should be employed throughout.
- Sync with Xero
- Downloadable transaction history for users, buckets and groups.
- Workflow to mark buckets as paid/reconciled, and for admins to reclaim (and properly re-distribute) money from any bucket, not just unfunded buckets.
- Birds eye view of current balances: allocated (pending and committed), and unallocated.
- Honor decimal places
There are many more desired features, but here I’m talking about a basic sanity threshold only.
Parting advice as we close out 2016
I spent about 40 hours until we had a process at Embassy Network that I was moderately comfortable with, and now that that the process has roughly converged, I spend about 4 hours/month to mange the the operational aspects of the process (mostly due to manual reconciliation and double checking).
Currently, I would recommend using Cobudget with strong caveats to your users, clear agreements around the primary source of truth, and with sympathy from them ensured. One-off projects are simpler, and many groups are also using the tool for “play money” or dot-voting on projects, which is of course much simpler than if you are dealing with real bank accounts. Ultimately though, if you need it to be precise and auditable, I would wait until sometime in 2017.
Feel free to get in touch if you have any ideas, want to discuss any ops questions, or to collaborate!