Defining transaction types

Our new Saftladen will sell fruit (»Obst«) and vegetables (»Gemüse«). It will also offer T-shirts with its logo (»Merchandise«) and it plans to take out a loan (»Kreditaufnahme«). These are all sources of revenue for our business, so our plan starts by defining them as types of revenue:

set_types(
    types=list(
        "Obst"=rgb(0.1,0.9,0.2,0.8),
        "Gemüse"=rgb(0.2,0.9,0.4,0.8),
        "Merchandise"=rgb(0.3,0.8,0.3,0.8),
        "Kreditaufnahme"=rgb(0.3,0.7,0.2,0.8)
    ),
    class="revenue",
    name="Saftladen"
)

»What about those rgb() colors?« you might ask. Transaction types are defined as a named list of colors. These colors are used by some of the package’s plotting methods to provide a quick visual overview. If you don’t use them, just set them all to white or whatever. The really important thing here is that each income source must have a unique named entry as a revenue here. This also forces you to think about these sources early on.

This set of revenue types is named "Saftladen". The name allows you to define several of these sets in parallel, e. g. if you’re modeling two businesses at the same time.

Note that this is not assigned to an object. Instead, set_types() is actually a wrapper for options() and adds this information to the options of the current session, as a named list called businessPlanR:

options("businessPlanR")

## $businessPlanR
## $businessPlanR$Saftladen
## $businessPlanR$Saftladen$types
## $businessPlanR$Saftladen$types$revenue
## $businessPlanR$Saftladen$types$revenue$Obst
## [1] "#1AE633CC"
## 
## $businessPlanR$Saftladen$types$revenue$Gemüse
## [1] "#33E666CC"
## 
## $businessPlanR$Saftladen$types$revenue$Merchandise
## [1] "#4DCC4DCC"
## 
## $businessPlanR$Saftladen$types$revenue$Kreditaufnahme
## [1] "#4DB333CC"

As for our expenses, we’re expecting to pay our employees (»Löhne und Gehälter«), social security contributions (»Sozialabgaben«), purchase goods (»Waren«), infrastructure (»Infrastruktur«), depreciation (»Abschreibung«), loan repayment (»Kredittilgung«), interest (»Zinsen«), and taxes (»Steuern«):

set_types(
    types=list(
        "Löhne und Gehälter"=rgb(0.7,0.2,0.4,0.8),
        "Sozialabgaben"=rgb(0.7,0.2,0.4,0.8),
        "Waren"=rgb(0.7,0.3,0.5,0.8),
        "Infrastruktur"=rgb(0.75,0.2,0.4,0.8),
        "Abschreibung"=rgb(0.9,0.2,0.4,0.8),
        "Kredittilgung"=rgb(0.9,0.2,0.4,0.8),
        "Zinsen"=rgb(0.9,0.2,0.4,0.8),
        "Steuern"=rgb(0.9,0.2,0.4,0.8)
    ),
    class="expense",
    name="Saftladen"
)

Consequently, each source of cash outflow must have a uniquely named entry as an expense here.

One object to hold them all

Before we look at individual transactions, we create an object of class operations. You might think of this as the closest thing you have to the tabs in Excel spreadsheets you may have worked with in the past, as it collects all sorts of financial movements in a structured way.

This operations object is like your complete business case, and it’s what most of the methods in this package expect as input: You throw them everything you’ve got so they can pick out the relevant bits.

This object also defines the time period your business plan will cover:

saftladen_2024_2026 <- operations(
    period=c("2024.01", "2026.12")
)

businessPlanR uses months as the smallest time resolution.

First transactions

With all revenue and expense types already set, we can now define the corresponding financial transactions. The methods we’ll use first are revenue() and expense():

# By default, revenues are repeated every month until
# the value changes.
rev_merch_2024_2026 <- revenue(
    type="Merchandise",
    category="Merch",
    name="T-Shirts",
    valid_types="Saftladen",
    "2024.03"=30,
    "2024.08"=40,
    "2025.03"=50,
    "2025.09"=70,
    "2026.02"=90,
    "2026.07"=100,
    "2026.10"=110
)

# We plan to produce our T-shirts in January each year.
# Since these expenses should not be repeated every month,
# we can set missing="0"; alternatives are "rep" for repeat
# (default) or "interpol" for automatic interpolation.
exp_merch_2024_2026 <- expense(
    type="Waren",
    category="Merch",
    name="T-Shirts",
    missing="0",
    valid_types="Saftladen",
    "2024.01"=200,
    "2025.01"=400,
    "2026.01"=600
)

Let’s look at the financial values of these objects. This can be done using get_value():

get_value(rev_merch_2024_2026)

##          type category     name 2024.03 2024.04 2024.05 2024.06 2024.07 2024.08
## 1 Merchandise    Merch T-Shirts      30      30      30      30      30      40
##   2024.09 2024.10 2024.11 2024.12 2025.01 2025.02 2025.03 2025.04 2025.05 2025.06
## 1      40      40      40      40      40      40      50      50      50      50
##   2025.07 2025.08 2025.09 2025.10 2025.11 2025.12 2026.01 2026.02 2026.03 2026.04
## 1      50      50      70      70      70      70      70      90      90      90
##   2026.05 2026.06 2026.07 2026.08 2026.09 2026.10
## 1      90      90     100     100     100     110

get_value(exp_merch_2024_2026)

##    type category     name 2024.01 2024.02 2024.03 2024.04 2024.05 2024.06 2024.07
## 1 Waren    Merch T-Shirts     200       0       0       0       0       0       0
##   2024.08 2024.09 2024.10 2024.11 2024.12 2025.01 2025.02 2025.03 2025.04 2025.05
## 1       0       0       0       0       0     400       0       0       0       0
##   2025.06 2025.07 2025.08 2025.09 2025.10 2025.11 2025.12 2026.01
## 1       0       0       0       0       0       0       0     600

As you can see, revenue() and expense() always calculate one entry per month. You can control these calculations directly via the missing argument (see the comment in the example). It is also possible to set a value with per_use, which will not use the numbers as actual financial values but, the number of times that value has been used. So if our shirts sell for 10 bucks and we start selling three shirts a month, this will give us the same numbers:

# By default, the sales are repeated each month until
# the value changes.
rev_merch_2024_2026 <- revenue(
    type="Merchandise",
    category="Merch",
    name="T-Shirts",
    per_use=10,
    valid_types="Saftladen",
    "2024.03"=3,
    "2024.08"=4,
    "2025.03"=5,
    "2025.09"=7,
    "2026.02"=9,
    "2026.07"=10,
    "2026.10"=11
)
get_value(rev_merch_2024_2026)

##          type category     name 2024.03 2024.04 2024.05 2024.06 2024.07 2024.08
## 1 Merchandise    Merch T-Shirts      30      30      30      30      30      40
##   2024.09 2024.10 2024.11 2024.12 2025.01 2025.02 2025.03 2025.04 2025.05 2025.06
## 1      40      40      40      40      40      40      50      50      50      50
##   2025.07 2025.08 2025.09 2025.10 2025.11 2025.12 2026.01 2026.02 2026.03 2026.04
## 1      50      50      70      70      70      70      70      90      90      90
##   2026.05 2026.06 2026.07 2026.08 2026.09 2026.10
## 1      90      90     100     100     100     110

The get_value() method can also show quarterly and yearly totals ("month" is just the default):

get_value(rev_merch_2024_2026, resolution="quarter")

##          type category     name 2024.Q1 2024.Q2 2024.Q3 2024.Q4 2025.Q1 2025.Q2
## 1 Merchandise    Merch T-Shirts      30      90     110     120     130     150
##   2025.Q3 2025.Q4 2026.Q1 2026.Q2 2026.Q3 2026.Q4
## 1     170     210     250     270     300     110

get_value(exp_merch_2024_2026, resolution="year")

##    type category     name 2024 2025 2026
## 1 Waren    Merch T-Shirts  200  400  600

Populating the operations object

At the moment, our two transactions are not yet part of our business case. We need to add them to our operations object:

update_operations(saftladen_2024_2026) <- rev_merch_2024_2026
update_operations(saftladen_2024_2026) <- exp_merch_2024_2026

Note that both transactions do not cover the full period we have defined: Missing months are assumed to have a value of zero. Also, we don’t really need individual transaction objects, we can assign the output of both revenue() and expense() directly to update_operations()<- or even operations(...).

With these few functions, you should already be able to write your own wrapper functions to implement many of the financial movements you need to cover. Because you can assign financial values to each month individually, you are free to write your own algorithms for whatever complex cash flows you assume, and combine all the results in an operations object.

There are also some additional functions to help you with very common tasks (or at least we’ve come across them so often that we’ve written functions for them):

• first_last() creates a list of two elements from January of the first given year to December of the last, both with the same amount specified.
• growth() calculates the differences between successive values in a numerical vector.
• regularly() creates lists of recurring financial transactions for given years (useful, for example, to define quarterly transactions, which may even have different amounts).
• regularly_delayed() extends regularly() to cover cases where you know the annual total of transactions, but they don’t start at the beginning of the year.
• calc_staff() calculates the number of staff needed to complete a given task.
• fin_needs() tries to estimate your capital needs from the cash flow.

Special transaction cases

There are also some additional object classes that cover additional types of transactions:

• loan() defines loans with interest and repayment schedule.
• depreciation() defines the depreciation schedule for defined items, i. e. your inventory.
• transaction_plan() calculates complete repayment and depreciation schedules from single or multiple loan or depreciation objects according to the specifics defined with these objects.

You can compare the transaction_plan class to operations, as both are structured collections of multiple objects. There’s also an update_plan()<- method to add or replace objects in existing transaction_plan collections, similar to update_operations()<-.

Simple modelling

Our goal, of course, it to have nice tables for our income statement or liquidity plan. Obviously, we can’t just turn the operations object into a table for this, but have to decide which of the statements are relevant for a particular type of table. What’s more, these are usually not just single large tables, but are structured into (probably even nested) sections.

So we need to define the structure for the tables we need, including the relevant transactions and their place in a table. This is done with the functions table_model() (which can do some validity checking) and model_node() (which is used »inside« table_model() for nested models. Don’t wonder too much about the term model here, we could have called it template or something.

Let’s sketch a very simple model that subtracts expenses from revenues to get an income statement:

saftladen_inc_stamt <- table_model(
    # Gross income from various sources
    "Bruttoeinnahmen"=model_node(
        revenue=c(
            "Obst",
            "Gemüse",
            "Merchandise"
        )
    ),
    # Gross revenue, i.e. minus costs of goods
    "Bruttoertrag"=model_node(
        carry="Bruttoeinnahmen",
        expense=c(
            "Waren"
        )
    ),
    # Gross profit, i.e. minus operating and depreciation expenses
    "Betriebsergebnis"=model_node(
        carry="Bruttoertrag",
        expense=c(
            "Löhne und Gehälter",
            "Sozialabgaben",
            "Infrastruktur",
            "Abschreibung"
        )
    ),
    # Operating profit, i.e. minus interest expenses
    "Gewinn vor Steuern"=model_node(
        carry="Betriebsergebnis",
        expense=c(
            "Zinsen"
        )
    ),
    # Profit after taxes
    "Nettogewinn"=model_node(
        carry="Gewinn vor Steuern",
        expense=c(
          "Steuern"
        )
    ),
    valid_types="Saftladen"
)

As you can see, we’re reusing some of the type names we defined for revenue and expense. Each type listed is used to calculate the sum for the node (as we call a named list in this context) in which it appears, with revenues added and expenses subtracted.

All entries must be named, here »Bruttoeinnahmen« (gross revenue) and »Bruttoertrag« (gross profit), as these names will be used in the actual table. Each node could contain child nodes (just add named objects with model_node()), so more complex hierarchical structures can be designed, but let’s keep it simple for now.

Providing valid_types="Saftladen" allows table_model() to check that all revenues and expenses have actually been defined, to avoid typos and missing values in our tables. Also note the use of carry="Bruttoeinnahmen" in the second node, which references the previous one. The effect of this is that the calculated sum of the referenced node is used as the initial value of the referencing node when calculating subtotals for each table section, before any revenues are added or expenses subtracted.

With an initial model defined, we can now condense our operations object into the tables we need:

condense(
    saftladen_2024_2026,
    model=saftladen_inc_stamt
)

##             Position        Type 2024 2025 2026
## 1    Bruttoeinnahmen Merchandise  350  660  930
## 2    Bruttoeinnahmen         Sum  350  660  930
## 3       Bruttoertrag       Waren -200 -400 -600
## 4       Bruttoertrag         Sum  150  260  330
## 5   Betriebsergebnis         Sum  150  260  330
## 6 Gewinn vor Steuern         Sum  150  260  330
## 7        Nettogewinn         Sum  150  260  330

Even from this very primitive example, you can see how condense() calculates subtotals (where Type is Sum) for each section (Position) of our model. Many methods in this package support the resolution argument, as we’ve already seen with get_value(), and so does condense():

condense(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="quarter"
)

##             Position        Type 2024.Q1 2024.Q2 2024.Q3 2024.Q4 2025.Q1 2025.Q2
## 1    Bruttoeinnahmen Merchandise      30      90     110     120     130     150
## 2    Bruttoeinnahmen         Sum      30      90     110     120     130     150
## 3       Bruttoertrag       Waren    -200       0       0       0    -400       0
## 4       Bruttoertrag         Sum    -170      90     110     120    -270     150
## 5   Betriebsergebnis         Sum    -170      90     110     120    -270     150
## 6 Gewinn vor Steuern         Sum    -170      90     110     120    -270     150
## 7        Nettogewinn         Sum    -170      90     110     120    -270     150
##   2025.Q3 2025.Q4 2026.Q1 2026.Q2 2026.Q3 2026.Q4
## 1     170     210     250     270     300     110
## 2     170     210     250     270     300     110
## 3       0       0    -600       0       0       0
## 4     170     210    -350     270     300     110
## 5     170     210    -350     270     300     110
## 6     170     210    -350     270     300     110
## 7     170     210    -350     270     300     110

This is just a raw data frame. But we can also use the kable_bpR() method on operations objects along with a table model to get nicely formatted tables in RMarkdown. The methods make heavy use of the kableExtra package:

kable_bpR(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="year"
)

Add more data

With only one revenue and expense stream, our plan is still not very meaningful. So let’s add some more transactions:

# Apples
update_operations(saftladen_2024_2026) <- revenue(
    type="Obst",
    category="Obst",
    name="Äpfel",
    valid_types="Saftladen",
    "2024.01"=2200,
    "2024.08"=3000,
    "2024.09"=3400,
    "2024.12"=2600,
    "2025.01"=2300,
    "2025.08"=3100,
    "2025.09"=3500,
    "2025.12"=2700,
    "2026.01"=2400,
    "2026.08"=3200,
    "2026.09"=3600,
    "2026.12"=2800
)
update_operations(saftladen_2024_2026) <- expense(
    type="Waren",
    category="Obst",
    name="Äpfel",
    valid_types="Saftladen",
    "2024.01"=1650,
    "2024.08"=2250,
    "2024.09"=2550,
    "2024.12"=1950,
    "2025.01"=1725,
    "2025.08"=2325,
    "2025.09"=2625,
    "2025.12"=2025,
    "2026.01"=1800,
    "2026.08"=2400,
    "2026.09"=2700,
    "2026.12"=2100
)
# Grapes
update_operations(saftladen_2024_2026) <- revenue(
    type="Obst",
    category="Obst",
    name="Trauben",
    missing="interpol",
    valid_types="Saftladen",
    "2024.01"=480,
    "2025.01"=590,
    "2026.01"=730,
    "2026.12"=820
)
update_operations(saftladen_2024_2026) <- expense(
    type="Waren",
    category="Obst",
    name="Trauben",
    missing="interpol",
    valid_types="Saftladen",
    "2024.01"=340,
    "2025.01"=410,
    "2026.01"=510,
    "2026.12"=580
)
# Potatoes
update_operations(saftladen_2024_2026) <- revenue(
    type="Gemüse",
    category="Gemüse",
    name="Kartoffeln",
    missing="interpol",
    valid_types="Saftladen",
    "2024.01"=2440,
    "2025.01"=2670,
    "2026.01"=2800,
    "2026.12"=2980
)
update_operations(saftladen_2024_2026) <- expense(
    type="Waren",
    category="Gemüse",
    name="Kartoffeln",
    missing="interpol",
    valid_types="Saftladen",
    "2024.01"=1950,
    "2025.01"=2130,
    "2026.01"=2240,
    "2026.12"=2400
)

Let’s look at the updated table:

kable_bpR(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="year"
)

It now summarises all the goods we have defined so far, grouped by type and placed according to our model. If you want to examine all the data in more detail, you can use the detailed view of the table:

kable_bpR(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="year",
    detailed=TRUE
)

Special transactions

As mentioned earlier, the package supports some common special cases of transaction plans. The idea here is to define a complete investment or loan repayment plan and let the methods of this package select relevant aspects of these plans for different tables, such as the profit and loss statement or the liquidity plan.

dep_cashreg1 <- depreciation(
    type="Abschreibung",
    category="Laden",
    name="Kasse 1",
    amount=450,
    obsolete=72,
    invest_month="2024.01",
    valid_types="Saftladen"
)
dep_cashreg2 <- depreciation(
    type="Abschreibung",
    category="Laden",
    name="Kasse 2",
    amount=450,
    obsolete=72,
    invest_month="2025.07",
    valid_types="Saftladen"
)

update_operations(
    saftladen_2024_2026,
    as_transaction=list(
        c(
            to="expense",
            aspect="investment",
            valid_types="Saftladen",
            type="Infrastruktur"
        ),
        c(
            to="expense",
            aspect="depreciation",
            valid_types="Saftladen",
            type="Abschreibung"
        )
    )
) <- dep_cashreg1
update_operations(
    saftladen_2024_2026,
    as_transaction=list(
        c(
            to="expense",
            aspect="investment",
            valid_types="Saftladen",
            type="Infrastruktur"
        ),
        c(
            to="expense",
            aspect="depreciation",
            valid_types="Saftladen",
            type="Abschreibung"
        )
    )
) <- dep_cashreg2

kable_bpR(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="year"
)

dep_plan <- transaction_plan(plan_type="depreciation")
update_plan(dep_plan) <- dep_cashreg1
update_plan(dep_plan) <- dep_cashreg2

kable_bpR(
    dep_plan,
    dep_names=c(
        investment="Investition",
        depreciation="Abschreibung",
        value="Wert",
        sum="Summe"
    ),
    resolution="year",
    years=2024:2029
)

loan_2024 <- loan(
    type="Kreditaufnahme",
    category="Bank",
    name="Anschubfinanzierung",
    amount=5000,
    period=60,
    interest=0.075,
    first_month="2024.01",
    schedule=c("amortization"),
    valid_types="Saftladen"
)
update_operations(
    saftladen_2024_2026,
    as_transaction=list(
        c(
            to="expense",
            aspect="principal",
            valid_types="Saftladen",
            type="Kredittilgung"
        ),
        c(
            to="expense",
            aspect="interest",
            valid_types="Saftladen",
            type="Zinsen"
        ),
        c(
            to="revenue",
            aspect="balance_start",
            valid_types="Saftladen",
            type="Kreditaufnahme"
        )
    )
) <- loan_2024

kable_bpR(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="year"
)

loan_plan <- transaction_plan(plan_type="loan")
update_plan(loan_plan) <- loan_2024

kable_bpR(
    loan_plan,
    loan_names=c(
        balance_start="Restschuld Beginn",
        interest="Zinsen",
        principal="Tilgung",
        total="Zahlung",
        cumsum="Kumuliert",
        balance_remain="Restschuld Ende",
        sum="Summe"
    ),
    resolution="year"
)

Modelling sales

Let’s go back to our example and try to do this for our apple sales. You have talked to local farmers and studied both the neighbourhood and consumer analyses. You have come up with the following figures:

assumed <- list(
    total_customers=1860, # number of potential customers?
    pct_year_1st=25,      # how many of them will buy at our store?
    pct_year_last=35,     # how will the number progress?
    pct_demand=30,        # how much will they buy from us?
    kg_per_customer=c(    # how many Kg were cosumed in recent years?
        apples=23
    ),
    exp_per_kg=c(         # how much will it cost to buy goods?
        apples=2.3
    ),
    rev_per_kg=c(         # at what price will we sell?
        apples=3.49
    )
)

In our business plan, we can now use this list of numbers to explain our expectations. The package has a function called nice_numbers() to format numbers, round them and add a prefix or suffix. So nice_numbers(assumed[["total_customers"]]) prints as 1.860, nice_numbers(assumed[["pct_year_1st"]], suffix="%") as 25 %, and nice_numbers(assumed[["exp_per_kg"]][["apples"]], suffix="€", digits=2) as 2,30 €:

According to the demographic analysis, there are a total of 1.860 potential customers for the Saftladen. We assume that we will reach 25 % of this market in the first year, increasing to 35 % in the third year as a result of our marketing efforts. We also assume that our average customer will buy 30 % of their annual apple requirements in our store. From consumer research in recent years, we know that the total annual consumption of apples per person is around 23 Kg on average. We have an agreement with local farmers to buy apples at 2,30 € per Kg, and we calculate a selling price of 3,49 € per Kg.

Great! So how many customers can we expect if these assumptions hold?

n_customers <- function(data, years){
    customer_pct <- seq(
        from=data[["pct_year_1st"]],
        to=data[["pct_year_last"]],
        length.out=length(years)
    ) / 100
    result <- round(data[["total_customers"]] * customer_pct)
    names(result) <- years
    return(result)
}

n_customers(data=assumed, years=2024:2026)

## 2024 2025 2026 
##  465  558  651

How many Kg of apples will we sell?

kg_sale <- function(what, data, years){
    avg_amount_total <- data[["kg_per_customer"]][[what]]
    result <- round(
        avg_amount_total * 
        (data[["pct_demand"]] / 100) *
        n_customers(data=data, years=years)
    )
    return(result)
}

kg_sale(what="apples", data=assumed, years=2024:2026)

## 2024 2025 2026 
## 3208 3850 4492

Apple season usually is from August to November, so let’s not spread this equally across the year:

spread_sales <- function(what, distribution, data, years){
    yearly_sales <- kg_sale(what=what, data=data, years=years)
    distrib <- round(as.vector(sapply(
        yearly_sales,
        function(kg){
            kg * distribution
        }
    )))
    names(distrib) <- paste0(rep(years, each=length(distribution)), names(distribution))
    return(distrib)
}

sales_apples_kg <- spread_sales(
    what="apples",
    distribution=c(
        ".01"=0.20,
        ".08"=0.27,
        ".09"=0.30,
        ".12"=0.23
    ),
    data=assumed,
    years=2024:2026
)

# multiply by prices
(sales_apples_expense <- round(sales_apples_kg * assumed[["exp_per_kg"]][["apples"]]))

## 2024.01 2024.08 2024.09 2024.12 2025.01 2025.08 2025.09 2025.12 2026.01 2026.08 
##    1477    1992    2213    1697    1771    2392    2656    2038    2065    2790 
## 2026.09 2026.12 
##    3100    2376

(sales_apples_revenue <- round(sales_apples_kg * assumed[["rev_per_kg"]][["apples"]]))

## 2024.01 2024.08 2024.09 2024.12 2025.01 2025.08 2025.09 2025.12 2026.01 2026.08 
##    2241    3022    3357    2576    2687    3630    4031    3092    3134    4233 
## 2026.09 2026.12 
##    4705    3605

Now we apply these figures to our operations object:

update_operations(saftladen_2024_2026) <- revenue(
    type="Obst",
    category="Obst",
    name="Äpfel",
    valid_types="Saftladen",
    .list=as.list(sales_apples_revenue)
)
update_operations(saftladen_2024_2026) <- expense(
    type="Waren",
    category="Obst",
    name="Äpfel",
    valid_types="Saftladen",
    .list=as.list(sales_apples_expense)
)

kable_bpR(
    saftladen_2024_2026,
    model=saftladen_inc_stamt,
    resolution="year"
)

Our previous revenues and expenses for apples have been replaced by update_operations(). Instead of a bunch of numbers that were hard to understand, these sales are now transparently derived from data that we have explained.