Ledger has a concept called a Periodic Transaction that is used to create a budget. Because ledger doesn’t understand fiscal years, ours look a little different than most examples, but they function the same way. We use these periodic transactions to allocate money to different uses.

In the Fedora project we manage our transactions a little bit differently. Normally you would budget your expenses. For example, you might think that you will spend $500 on rent and $300 on food in a month. In Fedora, we treat our budgets like credit cards (or checking accounts or current accounts). We then budget how much money we plan to spend out of each budget. All of this means that we budget negative numbers because we are planning to spend a certain amount of money. We do this because we know we want to spend no more than a certain amount of money on some activity, such as Flock, however we don’t decide at the beginning of the year how much we will spend on, for example, Lodging.

This example shows how the council allocated the total Fedora Public Budget to various activities in FY17.

In some cases this is the end of the budget allocation. For example, there is no sub-budgeting done for Flock. We plan and execute that event as a single unit. In other cases, for example in the Ambassador Regions, the money is divided into two or more layers or sub-budgeting.

Ambassador Regions are required to allocate their money into four quarters. This is to help with managing our spending rate. Some other areas of the project, for example FADs, are also often sub-budgeted, but not necessarily by quarter.

Sub-budgeting is pretty simple. It can be done in the file used by the specific area. Here is an example of how the NA budget my get broken down by quarter:

It works the same way as the council budget in the previous question. Notice that the order of the lines didn’t matter. Here they wrote the positive number first because it made sense to that region to think, "we had this money and we split it up like this." Again, everything adds to $0.

This can even be split further. Here is what an optional quarterly event budget might look like. This time the example is from EMEA.

There are two ways to fix this. Option 1, which is preferred, is to create another periodic transaction to change the budget. For example:

In this case $53 was moved from events in Quarter 1 to an event in Quarter 3. The comments make everything extra clear.

The other option is to just edit the budget entries. This is less preferred as it means you would have to go through the file’s history to discover there had been a change.

In Fedora we budget our events and items by the quarter in which they are expected to occur. In general, our budget items are small enough that it won’t change anything. Exceptions are large events like Flock. Doing this lets us make one budget entry for something like an event instead of having to make guesses about how much of the expense will fall in each quarter.

The goal of the budget is to make sure you have roughly allocated your expenses to occur in equal parts year round. There will definitely be exceptions as some things just naturally bunch up and some quarters are low on events/items. However, it should all roughly even out. Therefore we don’t need to worry about budgeting the exact costs in each quarter as long as the quarter where the item happens is accurate.

If we think about an event that will occur during Q3, we consider, from a budget perspective that all costs related to the event will occur in Q3. If we want to see when they really occurred we can look at the date of the associated transactions. This is kind of split brain, but doing it this way prevents us from having to budget the same event in two quarters or leave long non-machine parseable comments.

The budget is here to help everyone plan both the regions and the council. Therefore, it is helpful to think of the budget as your "notes about the future." Specifically, it is a good idea to immediately put things into the budget when they are approved. This way you can see reports of how much money you have left to allocate. When spending happens you’ll be able to see if the budgets were accurate and if there is any overage or underspend.

Here is an example, Using LATAM and some fictitious numbers:

The entry above divides the LATAM budget into quarterly budgets. Each quarter is broken down as follows

Here we have broken down a single budget quarter. Three events have been voted on and approved by the LATAM ambassadors. These are UNSACC LinuxPlaya, Cs50xni, and Flisol.

CryptoRave was originally approved (or considered) but then the event got canceled or we decided not to participate. Leaving the note here like this makes it easy to remember the event in the future or in next year’s planning.

SASO Conf is an event that LATAM has traditionally done. When the yearly planning was done a tentative $1000 was going to be used for this event. This event isn’t approved yet and hasn’t got a LATAM sponsor. It exists in this entry as a planning reminder. If the LATAM ambassadors start to run out of money making decisions on these kinds of events can help make decision about what trade-offs to make or whether to ask for more money.

At the end of the quarter we want to sweep any unallocated budget back into the main budget pot for reuse. To do this, change the last entry for the quarterly budget from Region:Q# to Region:Unallocated. The amount is automatically calculated.

Once you have processed all transactions for the end of the quarter, you may want to sweep the unspent money back as well. The easiest way to do this is to add as sweep line, as indicated below. The benefit of the sweep line is that it moves any unspent money back into the main unallocated pot so you can use it in future quarters.