A Matter of Perspective

When we conceptualize money flows, we often think of them in overly simple terms because it’s easy to think through. Something like this:

Then we get annoyed because there seem to be all sorts of problems with this incredibly simple flow. The thing is… it’s actually way more complicated. In reality even the simplest money flow looks a lot more like this:

That’s five teams and six steps, which is already a lot of coordination to get right. The sheer number of steps is only a small part of the problem though. The biggest issue is that each of these teams has a completely different way of thinking about the money they are working with. We call these perspectives.

So why is having different perspectives a problem?

Translating the data between perspectives is part of the problem, but even worse is that it’s often difficult for these different perspectives to understand when they are taking contradictory actions on the same money. Frustratingly, a lot of common approaches to solving this problem actually make it worse. We’ll outline some example perspectives below and talk about why their conflicting nature causes problems.

Perspectives

Let’s say you run a small business that is an insurance broker. You sell insurance policies to your customers on behalf of a number of different carriers. You take a commission on each policy you sell. Your basic flow and responsibilities look like this:

Here are some more details about each of these teams and their perspectives.

Same Money, Different Groupings

Billing and Accounts Payable are two perspectives that are particularly worth noting. Their perspectives are similarly shaped, but one needs to be grouped by customer, and the other by carrier. This is an example of two perspectives having competing grouping methods and cardinalities.

Problems

These perspectives are all pretty reasonable. Is it really a problem to go between them?

We’ve seen a single flow for a payroll processor have over $45m/year in losses stemming from perspective-based problems. That customer moves as much as $2b/day in payroll, so that number might seem insignificant; however, it had a big impact on both their free cash flow and their profitability.

Payroll is an extremely complex use case, however, so we’re using the simpler broker example to illustrate the problems.

The Context Problem

The perspectives we outlined above are very focused on the minimum amount of data needed to accomplish their responsibilities, and clean, modular handoffs between the teams. This is rarely the case in practice though. Most companies pick a single perspective and build their systems around it. It tends to be the product perspective, as that is how they think about making money and growth.

Let’s assume that’s the case here and think about Accounts Payable’s job if they need to operate in a product perspective.

Ultimately, they need to make payouts for multiple policies by carrier. However, the product perspective is focused on the customer, the policy, and the time period. Although the policy is useful for describing line items to the carrier, none of that other information directly maps to what we need to make payouts.

Instead, Accounts Payable will need to go look at the individual policies, find the premiums, find the carriers, and then try to figure out the payouts. The key problem here is context.

Ideally Accounts Payable wants to make sure that you’ve actually received the premiums from the customer before they pay, but the product perspective doesn’t know about that. They really need information from payments, but payments doesn’t care about policies, so to try to figure out if the customer has paid they need to go policy -> premiums -> bill for the premium -> transmissions for the bill -> confirmed transmissions. They’ll have to do this for every carrier/customer combination in the system.

So even though ultimately Accounts Payable only strictly cares about a couple of pieces of information, they now need to know the entire flow of money, and about every model along the way. They need to care about customers, policies, premiums, bills, transmissions, and confirmed transmissions.

This is the fundamental problem. Accounts Payable isn’t empowered to operate in just its own perspective, it gets forced into being deeply entangled with the entire product flow. This forces the team to understand product models and nuances of areas they aren’t experts in. They are also extremely vulnerable to impact from changes upstream, since they are tied to literally everything that comes before them.

That is what makes it feel like there is an endless stream of problems with your financial systems, and why you are spending so much time manually fixing things, or spending too much dev time on bug fixes.

The Reconciliation Problem

As you can see from the example above, having so many unique models requires hard translations and handoffs at each step. That much complexity makes it really difficult to properly propagate changes through the system. Each one of these model jumps (which can be far more complex than what we drew for this simple use case) creates an opportunity for losing or misunderstanding the money. This will ultimately surface as reconciliation problems when your accounts don’t match up to your system, and you’ll be spending time and money to reverse engineer what caused the problems to begin with.

However, if you could make it so that the model for the money stays consistent throughout the system, you could avoid these problems entirely.

Solutions

Anti-Pattern: The God Model

One common approach that fails consistently to help with these problems is to view it as a standard systems abstraction issue. We see customers try to build a “God” model that is a superset of everything that all these perspectives need. This is a mistake. Not only does the God model tightly couple all of your systems together, it doesn’t solve the biggest part of the problem. What makes these perspectives so different isn’t just that they need different data, but that they need to group the information by different dimensions, with different cardinalities.

Anti-Pattern: Golden Perspective

This is exactly the failure we walked through in the context problem. This often seems compelling because it’s easy to align with the core way you make money and grow your business. However, this asks every other perspective to fit a square peg into a round hole. The consistent shift between the golden perspective and the other perspectives will cause the system to become increasingly brittle, difficult to change, and more prone to losing track of money.

Native Perspectives

The solution here seems simple. Let each area operate on the money in the way that makes sense to them: their own perspective. However, changes they make need to be reflected in the other areas. This is a tough problem to solve… how do you let each team operate in their own way, but make sure it’s all in sync with meaningful guardrails between them?

This is where an operational ledger like String Theory comes in that can support multiple perspectives. The idea is that the system is built from the ground up knowing that different teams or systems will want to work with the same money while thinking about it in completely different ways.

String Theory solves this problem with its innovative approach to ledgering money combined with its group system. We track individual pieces of money, and allow you to attach any number of groups to it. Groups and other pieces of context stay with the money throughout its lifecycle in your system. This allows you to build a system that is built from the ground up to support multiple perspectives, and still be able to understand when two disparate areas are referencing the same piece of money.

Here is an example of how the handoff between product and billing might look built on top of String Theory.

This is a bit of a simplification, but you can see that the product and billing teams are able to operate on just the data they care about. In fact, when billing needs to make a payment it doesn’t need to talk to the product system at all. It just asks for money by the customer and time period. Since they are only adding a bill group to the money, it doesn’t change the product’s perspective at all. They can still find that money by its customer, policy, and time period if they need to check on it in the future.

Let’s move a bit further down the flow and look at a tricky example we used before: Accounts Payable. This time, Accounts Payable is trying to make a payout, but to make it even more interesting, there was a late cancellation on the incoming money from the customer.

Each of the areas (payments, accounts payable) are talking in the domain language that makes sense to them. Payments is dealing just with transmissions, and accounts payable is dealing with the confirmed premiums for the carrier, or payouts they created. However, when payments cancels the transmission, the attempted payout is automatically rejected. Since String Theory knows that they are both talking about the same piece of money it knows not to let Accounts Payable pay out money we never received in the first place. AP doesn’t need to know anything about payments, or understand the nuances of why a payment might be canceled after it was confirmed. As soon as payments makes the update, the two are automatically in sync since they are both actually operating on the same money.

This is the power of natively supporting multiple perspectives. The teams can focus on what they are experts in and still be unable to cause reconciliation problems within the system.

Conclusion

You’ll never be able to build your way out of these problems directly. No matter what perspective you pick, it will cause problems for all of the other perspectives. Even a God model, with all its tradeoffs, won’t solve issues with the teams needing to group the money in different ways.

The solution is to natively support mapping multiple perspectives to the same underlying model of money. That is how String Theory works by default right out of the box.