DEV Community: Formance

Structuring Invoices

Clément Salaün — Wed, 12 Mar 2025 13:48:11 +0000

Invoices are an important part of any business, as they provide the accounting justification for the movement of money. If you’re a merchant dealing directly with your customers, there’s really no question of how to issue or interpret invoices. But—more likely—if you’re a platform mediating the sales of goods or services between merchants and buyers, there are several different ways to handle invoicing, and it can be quite confusing to understand the various benefits and risks associated with each of the possible invoicing models.

In this article, let’s dive into three different models for invoicing as a platform and look closely at the implications for each. Some of those implications will depend on the region or regions you are operating in, your relationship with your merchants, and the degree of complexity for each of the three parties; It’s best to keep an open mind, and consider using a mix of these models to optimally handle the kinds of commercial situations you might encounter.

The Scenario

So let’s suppose you are a platform facilitating sales of goods, and you charge a flat percentage commission on all sales. You have a merchant with a listing on your platform for which they want to charge $80. And you have a buyer who is purchasing the product for a total of $100—the $80 plus your commission of $20. You collect the entire $100 purchase price, keep the $20 commission, and disburse the remaining $80 to the merchant on behalf of the buyer. How do you structure the invoices for that transaction? There are three options.

Model A: Customer Commission

On this model, both you and the merchant generate invoices to the buyer. The buyer receives an invoice from you for your fee of $20, and an invoice from the merchant for $80 for the product. On this model, the buyer is a customer of both you and the merchant.

This model simplifies your invoicing process, as you are only ever generating invoices on your own behalf, and passing responsibility to the merchant to invoice for the product sale itself. It also reduces the burden on the merchant by keeping their invoicing structure straightforward—the money they receive matches the amount on the invoice they generate.

On the other hand, the two invoices make the commission structure explicit to the buyer, which you might or might not want to do depending on your relationship with your buyers—it creates a risk that they might bypass your platform in the future.

There is an additional complication for the merchant, in that they are receiving funds from you, but invoicing the customer, which could create accounting difficulties for them depending on the accounting and taxation rules where they operate.

Moreover some regions have strict rules on platforms handling money on behalf of merchants (such as PSD2 in Europe), something other commission models handle much better.

Model B: Seller Commission

Another option is to have the merchant invoice the customer directly for the entire purchase price. You then invoice the merchant for the commission. The buyer is only a customer of the merchant now, and the merchant is your customer. This invoicing model is fairly common for platforms operating in Europe.

This is a much cleaner situation from the buyer’s point of view, as they receive only one invoice, and that invoice doesn’t disclose your commission model. It’s also cleaner from your perspective, because your only customers are your merchants.

However, it can place some burden on the merchants, depending on the tax structure where they operate, as they are likely required to recognize the entire $100 price as revenue, and the $20 commission as an expense which they might not be able to apply fully against their revenue. Additionally you will still run into regional rules, like PSD2, on handling funds on behalf of merchants.

Model C: Merchant Mode

There is a third option to consider, a more traditional approach (with a modern twist). On this model, you purchase the goods from the merchant, who invoice you. You then sell the goods directly to the buyer, invoicing them for the full amount. This is the usual model for brick-and-mortar stores that purchase an inventory from merchants for resale in a retail environment. The modern twist is that rather than keeping inventory, you make the purchase from the merchant just as the buyer is making the purchase from you—that is, using a just-in-time logistics model.

The advantage to this model is that invoicing is simple and clean for every party involved. In particular, you are not handling funds on behalf of the merchant. This model works well universally from an accounting and taxation perspective.

However, the downside is that you become the merchant of record for the sale. If the goods need to be returned or repaired, you as the platform become the responsible party for handling that. You can then pass along this responsibility to the original merchant, but you need to trust your merchants for this to work—it is entirely possible for them to fraudulently disappear after the sale is made, and you are left holding the bag. Implementing this model is therefore risky unless you have a demonstrably good relationship with your merchants.

How to Choose an Invoicing Model

Each of the three models presented above presents a different tradeoff of benefits and risks. Almost certainly you should consider your jurisdiction, the jurisdiction of your merchants, the complexity of the transactions, and your level of trust in your merchants on a case-by-case basis, and choose the appropriate model dynamically.

Model C, although straightforward from an accounting perspective, presents the greatest risks to you. Because you are responsible for the goods or services sold, you need to be able to trust your merchants. Moreover, employing this model means that the nature of your business activity might be rather different from a financial reporting perspective—you aren’t transacting as a platform in this case. On the other hand, Model C makes it easier to structure transactions involving multiple merchants because you are not handling funds on their behalf.

Models A and B trade off simplicity to reduce the risks to you of being held liable when a merchant disappears. However, as mentioned above, things get more complicated when multiple merchants are involved in a single transaction. In order to meet certain regional requirements, such as PSD2 in Europe, you will need to use a payment processor to handle the funds on your behalf. This can pose a problem if in a given multi-merchant transaction there is no common payment processor among the merchants. In these cases you will have to create a more complex set of transactions to comply with local regulations.

Model B presents the additional difficulty that it can be unfriendly to smaller merchants. For example, sole proprietors in France are required to report the full $100 of the transaction as income, increasing their tax liability.

Model A might be a better choice over Model B in that it is friendlier to merchants. However, it exposes your fee structure to your buyers, which may or may not be desirable.

Conclusion

Ultimately you will need to look closely at the details of your own situation to decide which trade offs are better for your business needs. But there’s no need to lock yourself into a particular invoicing model—you can dynamically determine which is better on a transaction-by-transaction basis. For example you could choose to default to Model A or Model B, and switch to Model C for merchants who have established trust with you.

How Not to Build a Ledger

Clément Salaün — Wed, 05 Mar 2025 15:10:00 +0000

So you’re an engineer, and you’ve been tasked with building a ledger to record funds movements across your platform. Building a robust, reliable ledgering system might not seem like a difficult engineering challenge, but a good understanding of accounting practices can help you avoid certain hidden traps that could derail your accounting.

In this article, we want to walk through some common anti-patterns in ledger design we’ve seen, point out those hidden traps, and arm you with the accounting basics you need to avoid those traps. You’ll be implementing more robust, reliable, and auditable ledgering systems in no time.

The Scenario

Let’s suppose we’re building an online marketplace for people to buy and sell their second-hand goods. Sellers can list an item for sale for free, and we take a 10% commission from the sale price when someone else buys it.

Suppose moreover that Bob has a guitar listed for $100, and Alice—our first customer!—wants to buy it. She will transfer $100 to us through a payment processor, and once she confirms receipt of the guitar, we will release $90 to Bob and take our $10 commission. How should we represent these transactions internally?

Zero-Entry Ledgers

Perhaps one of the most common ways to go about managing transactions is to have a table with account balances for each user. Here is an example of what such a table might look like. At the very start, all accounts will have a zero balance.

Account	Balance
Alice	$0
Bob	$0
Commission	$0

For Alice to buy Bob’s guitar, she first needs to make a payment to the platform for the total sale amount. We will update her account balance once we receive confirmation from the payment processor:

Account	Balance
Alice	$100
Bob	$0
Commission	$0

Two days later, Alice confirms receipt of the guitar, and we can release the funds to the seller, plus our commission. To record the result of the sale, we update Alice’s account balance to $0, Bob’s account balance to $90, and increase commission account balance by $10.

Account	Balance
Alice	$0
Bob	$90
Commission	$10

One of the reasons this model is so commonly deployed is that it is simple and straightforward—there is never any question of what each account balance is at any given time, it’s right there in the table!

Yes, But…

This is called zero-entry ledgering because we do not record the details of individual transactions, only the final results. It’s easy, but…this accounting model is deeply flawed, and represents a significant business risk.

Why? Because the balances are mutable. There is nothing in the design of this ledger to prevent a bug in your code (or a malicious actor, for that matter) from simply updating an account balance incorrectly.

Suppose for example, there was a bug in the commission calculation, and it was calculating a 10% commission when updating the seller’s account balance, but a 12% when updating the commission account balance, so we end up with final balances after the guitar sale that like this:

Account	Balance
Alice	$0
Bob	$90
Commission	$12

There is an extra $2 in the system now, which we won’t detect until we reconcile the balance with what’s in our actual bank account. And once we do find that we have an extra $2 in our ledger, we are utterly unable to answer important questions like: Where did this $2 come from? Which account or accounts is it in? How did it get there? Was it a mistake, or is this fraud?

Basically, with a zero-entry ledger, we’re flying blind. We cannot detect drift in our ledger before reconciliation. And we simply aren’t storing enough information about our transactions to understand how to correct any drift. This is a very risky situation we’ve put ourselves in.

But we can solve a lot of these problems by recording individual transactions rather than account balances in our ledger. Let’s see how this might work.

Single-Entry Ledgers

The next logical step many developers will take is to upgrade the system to a single-entry ledger, a ledger that stores information about individual transactions.

Instead of account balances, a single-entry ledger records information about individual transactions into and out of an account. Account balances are computed on the basis of all the transactions involving that account.

If you’ve ever had to balance a checkbook, or done household budgeting, these are examples of single-entry ledgers. Most small businesses—especially those that operate on a cash-only basis—use single-entry ledgers to manage their accounting.

Let’s retrace the example of Alice buying a guitar from Bob, and see how we would record that in a single-entry ledger.

Account	Amount	Date	Balance
Alice	+$100	20 Feb 2025	$100
Alice	-$100	22 Feb 2025	$0
Bob	+$90	22 Feb 2025	$90
Commissions	+$10	22 Feb 2025	$10

Now we have some more information. We can see that Alice initiated the sale on 20 February, when we charged her card for $100. Then, Alice verified receipt of the guitar on 22 February, at which point we released the funds from her account, and credited Bob’s account $90, and our commissions account $10.

Moreover, we can see the flow of money reasonably clearly. Unlike a zero-entry ledger, a single-entry ledger is immutable. Adding a new transaction creates a new line, rather than overwriting existing data. This allows us to attach timestamps to each transaction, so we can see how the ledger has evolved over time. This allows us to do some rudimentary tracing of funds, which is important for detecting and correcting drift in the ledger when we do reconciliation.

Not Out of the Woods

Although we are recording additional information that allows us to mitigate the worst problems of zero-entry ledgering, single-entry ledger still has some significant limitations. In particular, as our source of truth about the transactions that pass through our system, it is still susceptible to errors in entry that cannot be detected until reconciliation.

Let’s return to the example above where we mistakenly calculate our commission at 12%. After reconciliation, we can spot that the excess $2 is in the Commissions account, because we recorded that transaction. This can still happen because there are no constraints on how we record our transactions. And, real world ledgers tend to be a bit messier, and it won’t always be so easy to find once you have millions of accounts transacting with each other.

Moreover, we still don’t have a way to detect this error until we’ve done reconciliation. It would be nice if we could detect (and correct) it earlier. We need more data still.

Account	Amount	Date	Balance
Alice	+$100	20 Feb 2025	$100
Alice	-$100	22 Feb 2025	$0
Bob	+$90	22 Feb 2025	$90
Commissions	+$12	22 Feb 2025	$12

There is another question we cannot answer, one that our finance people very much need to be able to answer: Which balances are assets, and which are liabilities? We’re holding $100 in the bank—that’s an asset. But we owe Bob $90 (and the Commissions account $10)—these are liabilities. But this isn’t encoded in any way in our ledger, so our accountants cannot generate balance sheets for our business, and they cannot tell us whether our books are out of balance. We might appear to be flush with cash, when in fact we’re operating in the red.

Double-Entry Ledgers

Double-entry ledgers take the idea of recording transaction individually, but add a critical constraint that must be applied to each transaction as recorded: A change on one account must always be balanced by an opposite change on another account. This constraint ensures that we will never record a transaction that makes money appear out of or disappear into thin air, unlike the simpler models discussed above.

To do this, we’ll add two details to our ledger. First, we split the “Amount” column into “Debit” and “Credit” columns. Second, we label each account as being an asset or a liability. Any account that is holding money for someone else, like our customers, is a liability. Any account that holds revenue, like our commissions account, is also considered a liability (at least until we’ve paid out the vendors). Any account that represents actual cash in our hands is an asset.

Next, we need to note two important rules for recording transactions.

The first rule is that:

Assets = Liabilities

Put slightly differently, every transaction must contain one or more debits, one or more credits, and the total of those debits must equal the total of those credits.

This ensures that after each transaction has been recorded, when we sum the assets and sum the liabilities, those will be equal to each other. This is how we ensure that no errors have been made when recording a transaction.

The second rule is that:

• A *debit* increases an asset, or decreases a liability.

• A *credit* decreases an asset, or increases a liability.

This rule tells us how to record each transaction properly, and how to properly sum assets and liabilities.

Finally, a little additional terminology. An account that represents an asset is called “debit normal”, because debits increase the value of the account. An account that represents a liability is called “credit normal”, because credits increase the value of the account. So, let’s note that the Payments account is our only debit-normal account; the remainder are credit-normal.

Let’s put these ideas to work!

Account	Debit	Credit	Transaction	Date
Bank (Debit)	$100		0001	20 Feb 2025
Alice (Credit)		$100	0001	20 Feb 2025

On 20 February, Alice makes a card payment to us in the amount of $100. But we can’t just record that Alice’s balance has increased by $100—we must balance credits and debits! So we introduce a new account, our bank account, where that money has been deposited. And because this is cold, hard cash in our bank account, it is thus an asset. That said, the money belongs to Alice, it’s not our money. So we record her credit card payment as a debit to the Bank account (an increase in $100 in assets), and a credit to Alice (an increase in $100 in liabilities—because we owe this money to Alice).

So far so good! Our debits ($100) equal our credits ($100).

Next, Alice receives the guitar, and we release the funds to Bob (and take our commission). Because we want to remove money from Alice’s account, which is credit-normal, we mark the $100 payment as a debit on her account. We deposit $90 into Bob’s account, which since it is also credit-normal, is marked as a credit. Likewise, our $10 commission is marked as a credit in the Commission account, because it is also credit-normal.

Account	Debit	Credit	Transaction	Date
Bank (Debit)	$100		0001	20 Feb 2025
Alice (Credit)		$100	0001	20 Feb 2025
Alice (Credit)	$100		0002	22 Feb 2025
Bob (Credit)		$90	0002	22 Feb 2025
Commissions (Credit)		$10	0002	22 Feb 2025

In this transaction, we debited $100 from Alice’s account, and we credited $90 to Bob’s account and $10 to the Commissions account. Our debits ($100) equal our credits ($100) for this transaction, so it is valid.

Moreover, we can see after these two transactions that our assets equal our liabilities. After the first transaction our assets were $100, and our liabilities were also $100. In the second transaction, the debit to Alice’s account adds $100 to our assets (because we no longer owe her that money, as she no longer owns it, having exchanged that money for the guitar). The credits to Bob’s account and the Commissions accounts are a liability, so we add $90 and $10 to our liabilities.

Now:

Assets = $100 + $100 = $200

And:

Liabilities = $100 + $90 + $10 = $200

Our Assets remain the same as our liabilities, so we know everything is correct!

What Have We Gained?

We can now answer a very broad range of important questions about the money movements recorded in our ledger. In particular, we can make strong guarantees that our ledger is free of drift resulting from the incorrect entry of transactions, because the constraints of double-entry ledgering make it is impossible to create or destroy money with an invalid transaction. Of course, drift can still happen if a transaction isn’t recorded, or is recorded more than once, but this isn’t a problem with the ledger itself.

Moreover, we can see both sides of a transaction very clearly, which makes funds traceability much easier. We know with certainty that the $90 in Bob’s account came from Alice’s account, because of how transactions are recorded. Even with millions of accounts transacting, there is never a question of where the money in each account came from and why.

Moreover, because we have a very clear picture of our assets and liabilities, our accountants can create balance sheets and other documents to show investors and regulators that everything is being accounted for.

Conclusion

Creating a robust, scalable, auditable ledgering system requires more than sound engineering principles, it also requires a basic understanding of accounting principles as well.

Zero-entry ledgers are the easiest to implement, but offer no assurances against errors or fraud—it is trivially easy to create or destroy money when writing an account balance. They also offer no information about how accounts change over time, making it impossible to trace the movements of funds.

Single-entry ledgers are only slightly more complex to implement, as you are recording a chain of individual account balance changes over time. This historical data makes it somewhat easier to spot errors and fraud, and offers a rudimentary possibility for tracing the movements of funds.

Double-entry ledgers are the gold standard for recording transactions. The constrained structure of entries offers built-in assurance that each transaction is being recorded correctly, and makes it clear where the money is coming from and where it is headed. The possibility of errors and fraud hiding in the ledger is eliminated from the ledger (though obviously there are plenty of other ways for this to happen!), funds traceability is greatly increased. And our accountants can now produce the documents they need to reassure investors and regulators that our business is operating properly.

Level up your secrets management in Kubernetes using AWS Secret Manager and Helm

Julie Hourcade — Mon, 26 Dec 2022 09:04:11 +0000

Engineers' biggest struggle when writing Kubernetes resources is to keep all secrets secure. To be honest, the secrets k8s resource is not secured at all because base64 is not encryption!

Required skills:

Understanding basic concepts about Kubernetes
Cloud providers resources knowledge
Helm v3 installed on a Kubernetes cluster.

Understanding Helm

For this article and for Formance infrastructure we chose to use Helm as a templating system for our k8s resources. This software is commonly known as the package manager for Kubernetes but they also provide a good system for deploying many versions of the same Charts, like for production and staging environments.

Initialize the application

First, we have to create a new application using the Helm CLI. You could find how to install it here: https://helm.sh/docs/intro/quickstart/. Once all is installed correctly, you could run the command:

helm create "<your_application_name>"

The directory Helm creates should look like this ⬇️

In this article, we’re going to stay basic and remove some templates to keep it simple. We’re only keeping:

The deployment template
The service template
The service account template
The helpers, Notes, and Tests

Finally, we will create a file named secret.yaml for the template of our SecretProvider object.

If you’re not familiar with the Helm templating language, I recommend you take a look at the documentation: https://helm.sh/docs/chart_template_guide/

The secret provider object

Concept

What are CSI Drivers?

To perform what we want, we’re going to use a Kubernetes resource named SecretProviderClass from the API secrets-store.csi.x-k8s.io/v1alpha1. The secret store is provided by the Kubernetes Container Storage Interface which here helps us to connect basic resources like volumes or secrets to cloud providers' services.

The main problem of Secrets resources on Kubernetes is the lack of security and if I want to share some private values as database passwords to my application deployment, I need more than just a base64 encryption.

Here at Formance we use Amazon Web Services as cloud provider so I will use the service AWS Secret Manager (docs: https://docs.aws.amazon.com/secretsmanager/?id=docs_gateway). When we have created our Relational Database Service with MariaDB or PostgreSQL or whatever, using InfraAsCode tools Terraform, we have automatically created a Secret with the database login information. The problem is to retrieve those values directly on my application container automatically.

Simplified overview of the workflow

Installing the Secret Store CSI driver

That’s here where Kubernetes CSI enters in action ! It will create an interface between our Secret object on AWS and our application deployment. First of all, we have to install the Secret Store CSI driver using helm.

helm repo add secrets-store-CSI-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver --namespace kube-system

You could find an alternative installation here: https://secrets-store-csi-driver.sigs.k8s.io/getting-started/installation.html

It will install things like the operator, and service account with the right RBAC permissions and most important, it will declare the Custom Resources Definition of the SecretProviderClass. Without this, the Kubernetes Scheduler will not understand the API version and the object kind.

Secret store CSI driver also supports GCP, Azure, and Vault secrets providers.

Deep dive into the secret template

The requirement is to make a template where we could inject some specific values like:

The name obviously
The secret provider (note that this example is only tested on AWS)
And the secrets to retrieve using the secret name or in AWS its Amazon Resource Name (ARN)

Keep in mind that this example is a simple template with multiple secrets but you personalize it as you wish. You can find various

Let’s take a look at the template and its values:

Once you create all templates, all you have to do is to apply the command:

helm install <application name> .

And you're all done!

Image credits: Midjourney

Building an Uber Eats Clone

Julie Hourcade — Thu, 02 Jun 2022 11:43:29 +0000

Initialy published on https://32b6.com by Clément Salaün

Templating money flows with Numscript

We explore in this article the money problem behind creating a food delivery platform, focusing on building the core money movements using the Formance ledger and Numscript as the foundation of our real-time accounting system.

The Three-sided Platform

From a money flow perspective, Eats is a classic n-sided marketplace (where N=3). It is a machine that reads your credit card details, materializes a pizza on your porch and a platform, facilitates a transaction between three parties: the customer, the restaurant and the rider.

Some payments services providers give us constructs to route an incoming payment, to a certain extent. Stripe Connect for example has destination charges, which give you the ability to provide the end destination account and your commission amount at payment. This is not super helpful for our food delivery app given that:

We have more than 1 destination (the restaurant and rider)
We don’t know, at payment time, who is going to be the rider

To these issues, Stripe answers with another turnkey solution called separate charges and transfers. It basically solves all our concerns, at one cost: we are now responsible for tracking what is owed to whom. Ledger systems are a good candidate for achieving this, as we’ll attempt to demonstrate in this article.

Templating our flow

Not bothering with unique values (for now), let’s start to encode our money flow in Numscript using hardcoded values. If you want to follow along, Numscript files can be executed against a locally running Formance ledger directly from the cli:

numary exec "eats-clone-demo" example.num

The payment

Using an intermediate payment ledger account helps us divide our flow into multiple sub-problems. Prior to splitting, our first mission is to properly track how much we collected from our customer. Let’s start with a simple case by assuming we managed to collect $59 through Stripe:

We use here the @world account to introduce money into our ledger (as per the spec). If its USD balance was zero before this transaction, it will now be negative 59. We can note as well that we use here USD/2 instead of USD, which is basically a notation for USD scaled to 10^-2 i.e. USD cents.

We conclude the payment by flushing the funds we collected to an order account, which will receive the funds without ever bothering about their origin:

Philosophically, we consider stripe as an external ledger that now owes money to our local ledger. In the real world, money hasn’t moved but we penciled in that this money is now dedicated to this order.

The split

Moving further in the flow, we now task ourselves with splitting the customer payment to the rider, restaurant and our platform. This splitting script is typically where we would encode our platform commission logic. We make the decision here of taking a 15% cut on each amount we pay the restaurant, leaving the delivery fee entirely to the rider.

The payout

We now have riders and and restaurants accounts in our ledger with a positive balance, whose purpose is to eventually be paid out to their owners’ banks.On the rider and restaurant views of our app, we’ll typically display these balances as “available for payout” funds.

Sticking to Stripe, one way to achive the processing of these balances can be to move the balance from a restaurants:001 account to a restaurants:001:payouts:001 account, initiating a transfer and a payout on Stripe of that amount, and eventually moving the balance from restaurants:001:payouts:001 back to world once we successfully processed the payout.

Automating our flow

Using hardcoded values in Numscript will only get us so far. As we start to execute our templates automatically from a backend, we will typically start to use variables, passing them along with the script on the /script endpoint

Using execution variables

Using a commission from metadata

As we iterate with our platform economics, we’ll likely end up with different commission rates per restaurant. We can inject this commission as a variable as well, fetching it the example below from the restaurant account metadata:

More complexity

Coupons

Inundating the buy side with generous coupons is a common strategy to break the chicken and egg problem platforms face. If you’re really going for an Eats clone, you may subsidize the buy side so much that you’ll end up spending more for a purchase in discount than the commission you’ll get out of it:

In the grand scheme of the above example, as a platform, we are $8 short overall. If this was the only payment flow to ever happen on our Stripe account, we wouldn’t be able to cover payouts to the rider and restaurant.

As we rinse and repeat this process for thousands of sales, it becomes critical to properly track these marketing losses to avoid putting ourselves at risk of ever defaulting payouts.

Numscript comes with multi-sources transactions which we can use to model our marketing expense. Let’s first credit $15k to a coupon account for a specific campaign:

Then in script executing at payment time, we’ll use this coupons as a source of marketing funds, from which we’ll draw up to $19.

Refunds at loss

So, the food arrived colder than it left the freezer at the restaurant. Customer files a ticket and you can’t know for sure wether the weather, rider, or restaurant is at fault here. As a platform you may decide to eat the loss, issuing a partial refund to your customer.

Properly registering this loss as a money movement in our ledger will, in addition to keeping the books in check, once again help us prevent defaulting risk as we’ll be able to create routine processes of topping-up your Stripe platform account to cover for losses.

Reconciliation

The internal flow we defined in blue sits between input and output. It tracks what is owed to whom, and only makes sense if it eventually supports actual money movements in the real world, which we achieve through payments processors.

Recon is a complex payments 101 problem. We want to make sure that assumptions we make in our system, e.g. that we received $59 from our customer, hold true in the external systems we use over time. As an example, your customer may charge back their payment after a few weeks, breaking your reconciliation. Ideally, every payment on your provider should be linked to an internal ledger transaction. In a further article, we’ll cover techniques and scripts to continuously reconcile our flows.

Notes on legal design and compliance

We mentioned defaulting risk a few times in this piece. I’ve heard objections to this concern, usually quoting perpetual growth combined with positive cash float as a mechanism to make up for platform losses and marketing expenses. This can only be true if properly measured with a ledgering strategy and to the surprise of no one, auditors are not particularily fond of this scheme, no matter how exciting the idea of a fractional-reserve marketplace sounds on paper.

In any case, your local lawyers are the best advisors on what you can and cannot do with your payments flows.

Conclusion

As a platform, having a holistic view of your money flows and being able to know at any point in time what is owed to whom is critical. Using a ledger-oriented programmation model will help us achieve both reliability and visibility, as immutable transactions become the fundamental construct of state in our system.