Withdraws & Debt

String Theory has very rigid financial integrity constraints, which means that it handles withdraws differently then other systems you may have used. In this section we'll cover how withdraws work, how debt is handled, and why the system acts the way it does.

No overdrafts

When working with money in String Theory you can only withdraw from knots. If there isn't any knots containing the money you want to withdraw, then the withdraw cannot happen. This means that its impossible to withdraw more money from an account than it currently has.

This is a good thing, and its intentional. String Theory lives by a principle when dealing with withdraws:

This might seem strange to you, if you've ever used a sum based ledger (like double entry) where adding debt to an account reduces the balance, but there are lots of reason to avoid this behavior. We'll cover several below.

Implicit debt causes business risk

Let's say you are running a marketplace business (e.g. Amazon). You sell products listed by vendors, then pay your vendors for a portion of the sale. You have a vendor named John who has $100 in his seller account that he is owed. Unfortunately, when paying John your system makes a mistake and makes two payments of $100 instead of one. This puts John's account at -$100.

Even though a business error happened, everything in this situation satisfies the constraints of double entry accounting. The starting balance and ending balance are the same. All transactions sum to 0. This is pristine accounting, with no errors.

Let's break down what happened here, though. Due to a processing error, we gave John an interest free loan from our operating accounting with no terms or payback requirement. If our operating account is using a line of credit, we may now be paying interest on a loan we didn't even intend to make and legally can't charge John interest on. Even if we aren't paying interest on what we've loaned him, we are still losing money we could be making on interest from having it in the bank, or invested somewhere.

The real question is: why is this even allowed? We haven't budgeted any money for loans to John, and even if this is ok we definitely want the maximum amount to be constrained. This could've been a $100,000 overpayment instead of $100, and it would still be "fine" by double entry standards.

These problems are solvable (though its harder than you might think) however, it is going to require you to build multiple systems around your double entry ledger that support these things. You'll need a system need to reject seller accounts going below 0. Another system will need to manage budgeting and attribution for acceptable debt. Yet a third system will need to map the types of accounts to their financial rules. It's a lot, and its complicated.

The explicit debt model

String Theory handles these issues with an explicit debt approach. This means that adding debt to an account is always an intentional action, and can't be done implicitly as part of a withdraw. When adding debt you are required to specify where the money for the loan is coming from, and that amount needs to be available from the lender. Let's explore the same example from earlier.

Again we have a vendor John who has $100 in his seller account (made up of 2 knots K1, K2, distribution pictured below). Unfortunately when paying John the system makes a mistake and tries to do two withdraws from John's account.

Here is the break down of what happens in the String Theory system when the double payment attempts to process:

1. Withdraw 1 comes in asking for $100
2. Two available knots are found that sum to $100: K1 and K2
3. Both knots are withdrawn from the system and become K3 and K4 respectively
4. Withdraw 2 comes in asking for $100
5. Withdraw 2 is rejected because no available positive amount exists for John that can satisfy the amount

Simply stated: in order for money to be withdrawn from John the money must first exist in the system. This protects your system from un-intentional losses of money, unaccounted for debt, and system error with unbounded financial impact.

Working with explicit debt

Q: What if lending John $100 was intentional? Doesn't the system stop us from doing that?

Not at all, it just requires you to be more explicit about what is happening. Let's say that we sometimes give John a partial advance on big orders as an intentional business rule. Instead of a single instruction (withdraw $100 from John) we'll need to give it two instructions:

1. Loan John $100 from the seller advance budget
2. Withdraw $100 from John

This extra instruction protects you in lots of ways. First, John only gets the extra $100 if we tell the system we want it to happen. No bonus money, even if your system is the one ultimately responsible for the mistake.

Next, the total financial impact from seller advances is limited by the seller advance budget. If there isn't enough money left in that budget, John doesn't get the loan. This allows for a high level of financial discipline while still providing a nice operating experience for your sellers.

Finally, the -$100 debt that John is left with is traceable to where it came from, why it was applied to the account, and reconciliation instructions. Whereas in the double entry style the only context would be the withdraw instruction, which only provides context on why you wanted to pay John.

One of the bigger lies we tell ourselves in finance is that reconciling debt (zeroing out debt with a positive amount) is simple and straightforward. In the easiest possible world, you just sum up the account and look at the balance, so any debt applied is immediately reconciled against the balance. However, debt is rarely handled in such a straightforward manner in the real world.

Let's use the previous example to illustrate our point. Let's say we want to loan John $100 because he just got a big purchase order, and he might need capital to buy materials or other expenses involved in a large order. The end goal is that John, as a business, has $100 more cash flow in order to fulfill that order.

On the same day, however, John ships a $30 order and is now entitled to (and expecting) a $30 payout.

We'll start by using illustrating an automatic reconciliation strategy (the only one double entry supports) using a double entry table.

In this example John's shipped sale (illustrated by T2) is immediately applied against the $100 we loaned him earlier in the day, leaving him with -$70 dollars. We don't pay anything out to John for T2 because he has no positive balance. We definitely want to collect on the $100 loan eventually, but is this really correct?

This behavior has left John with effectively only $70 in positive cash flow, instead of the intended $100. Hopefully, that's enough to be able to work fulfill the big order for T1, but John and our company are both going to provide a crappy experience to the customer.

A better way to approach this debt would be to only apply the debt to the payout John will be due when he completes the order for T1. That way John would get the $30 they're expecting (and had maybe already spent) as well as the $100 loan we intended to give them. However, to model this behavior in double entry is very difficult. You'll need multiple debt accounts for John that will represent the debt for different reasons. Additionally, to make the double-entry math work out, those debt accounts will need to have positive balances.

The complexity to model this grows out of hand very quickly, and is a large contributing factor to why many businesses behave poorly, or erratically when it comes to handling debt.

Explicitly reconciled debt

Since String Theory knows about each separate piece of money (or debt) and it's context so you can be intentional about how you reconcile debt. If it doesn't make sense to reconcile the T1 debt with T2 you can just choose not to. Similarly, if it is ok to reconcile any income with the debt, but just not right away you can freely choose that option too.

String Theory will allow positive amounts to be withdrawn, even if debt is present, as long as you haven't configured it not to. Even when this happens, however, it still ensures financial integrity by not allowing more debt to be implicitly created.

Let's look at the loan example as would work out in String Theory.

The final state of John's transactions are: a $100 payout from Payout 1, a $30 from Payout 2 and a balance of -$100 (K5) owed to us by John. This is exactly what we wanted, and we didn't have to do any extra work to get it.

Q: Why is Payout 2 allowed?

Payout 2 doesn't violate String Theory's financial integrity constraints because there is a current and available positive amount (K7) that can be withdrawn from John. Since we chose not to reconcile John's debt against K7 there is still available money, even though John will need to repay K5 eventually.

The important thing here is that you have a choice. You can choose to immediately reconcile K7 with K5 or you can choose to apply more complex business rules based on your goals. String Theory gives you that freedom.