In this article
The invoice is one of the oldest instruments in commerce. A supplier delivers goods, issues a document stating what is owed, and waits. That wait — thirty days, sixty days, ninety days — is where working capital dies quietly, a little at a time. Tokenization does not change the wait itself; the debtor still pays when the debtor pays. What changes is everything that happens in the moment of collection: who gets how much, when, and with what certainty.
For the professionals who structure, service, and administer these facilities — originators, pool administrators, servicers, fund accountants, settlement agents — the collection moment has historically been the most operationally fragile part of the entire arrangement. Funds arrive in a servicer account, a waterfall spreadsheet runs, wire instructions go out to senior investors, then subordinate investors, then the originator's reserve, then an origination fee account. Each step is a hand-off. Each hand-off is a day, and sometimes two. Each day is a reconciliation problem.
This article works through the mechanics of a tokenized invoice pool, from origination through to the moment collected funds hit every entitled party simultaneously, in one atomic transaction, with no residual ambiguity about what moved where.
From the worked scenario below: a pool of 48 invoices with a senior tranche, a junior tranche and an originator residual.
What a tokenized invoice pool actually is
Tokenization of real-world assets for trade involves representing trade-related assets — such as invoices, receivables, supply chain finance instruments, and letters of credit — as digital tokens on a blockchain. An invoice pool extends that principle to a collection of individual receivables rather than a single instrument. Rather than tokenizing one invoice from one supplier, an originator assembles a portfolio of verified, accepted invoices and creates a pool. A vault pools capital, often from many investors, and automates the operational layer that used to require a fund administrator, a transfer agent, and a stack of spreadsheets.
The pool structure matters because it creates diversification. A single invoice carries single-obligor risk: if one buyer delays or disputes, the investor holding that token bears the full impact. Pools split into senior and junior slices, so a conservative lender takes the first-loss-protected tranche at a lower rate while a risk-tolerant one takes the junior tranche for more upside. That is ordinary structured finance, rebuilt on rails where anyone can audit the pool.
The lifecycle of individual receivables within the pool looks like this. The lifecycle of a tokenized invoice involves several distinct stages that move the asset from origination to settlement. The process begins when a supplier generates an invoice for goods or services rendered. Rather than emailing a PDF to the buyer, the supplier submits the invoice data to a tokenization platform. Before an invoice can be minted as a token, the platform must validate its authenticity to prevent fraud. This often involves checking the creditworthiness of the buyer and ensuring the invoice has been accepted by the debtor. Once verified, the platform mints a digital token representing the invoice. This token is typically issued as an NFT because each invoice has unique characteristics, such as specific counterparties and values, making it non-fungible.
Once a sufficient number of eligible invoices are minted and verified, they are deposited into a pool smart contract. The issuer typically creates a legal wrapper, often an SPV incorporated in a jurisdiction with favorable regulatory treatment. This entity holds the underlying asset and issues tokens representing fractional ownership or claims against the asset pool. Token holders — senior investors, junior investors, the originator retaining an equity slice — each hold a digital representation of their claim against that pool.
The parties around a tokenized invoice pool
Understanding the distribution mechanics requires first mapping who is present and what they are owed. In a standard structure the parties typically include:
The originator. The entity that sources the invoices, either directly from supplier clients or via a platform marketplace. The originator is typically entitled to a servicing spread or residual equity position — the excess of collections over investor returns.
Senior note holders. Institutions, fund vehicles, or treasury desks that have provided first-loss-protected capital. The senior lender often receives the first minimum interest payments. The remaining balance is then distributed in a systematic fashion. In practice this means senior holders are the first to receive principal and their agreed coupon rate from any collection event.
Junior / subordinate token holders. If the deal goes sour, the subordinate lenders are often the first to lose their investment. As such, they usually require a higher rate of return than the senior lender. Their tokens absorb losses before the senior tranche is affected; in exchange they receive more yield when the pool performs.
The pool administrator. Responsible for verifying that eligible invoices meet concentration limits, tenor limits, and credit criteria on an ongoing basis. Some strategies use pooled assets with eligibility tests, concentration limits, and controlled collections. These features can align well with digital reporting.
The servicer. The entity that monitors outstanding invoices, follows up on overdue amounts, and — critically — receives collections from debtors. In many structures the originator and the servicer are the same entity, but the roles are legally separated so that a servicer replacement event does not affect the underlying pool ownership.
Reserve and fee accounts. Most pools maintain a liquidity reserve (funded by the originator or deducted from collections at closing) and may route a portion of each collection to a credit enhancement reserve before distributing to investors.
Each of these parties has a contractually defined entitlement to a share of each collection. The traditional process of calculating those shares, moving funds through banking intermediaries, and confirming receipt can span three to seven business days. Settlement moves from T+2 banking cycles (two business days) to near-instant capital circulation when the routing is handled onchain.
The traditional collection problem, in detail
Before examining what onchain routing solves, it is worth being precise about where the friction actually lives in the legacy process. The problem is not that servicers and administrators are slow — most are operating within the constraints of the systems around them. The problem is that the systems are sequential by design.
- The debtor paysA debtor pays their invoice. The payment lands in the servicer's collection account, which is a bank account, often at a custodian bank.
- The payment is matchedThe servicer's back office identifies the payment, matches it to the invoice in their origination system, and marks it collected.
- The waterfall runsThey then run the distribution waterfall, which is almost always a spreadsheet or a proprietary calculation engine sitting outside the blockchain entirely. The waterfall calculates: senior coupon due, senior principal, junior coupon due, junior principal if any, reserve top-up, origination fee, servicer spread, residual to equity.
- Wires go outEach output of that calculation becomes a wire instruction. Wire instructions go out through the servicer's bank, which may have cut-off windows. Legacy wire systems rely on commercial bank operating hours and batch processing cycles.
- Funds arrive at different timesSenior investors in one jurisdiction may receive funds same day; junior holders in a different time zone may wait until the following business day. The originator's residual may not clear until a day after that.
Professional servicing means the waterfall runs the same way on every payment cycle, with a distribution statement that shows exactly what came in, what left at each tier, and what landed in each investor's account. The challenge is that even when that professional discipline is present, the execution is still fragmented across multiple banking rails, and each step introduces timing uncertainty. Most servicing agreements specify a distribution lag — typically 5 to 15 business days after the payment clears.
That lag is not just an inconvenience. It is a systemic drag on capital efficiency. Stablecoin use cases tend to emerge precisely where traditional rails face structural problems: cross-border settlement timing, high FX costs, trapped liquidity, delayed finality, and complex payout workflows.
How onchain routing changes the moment of collection
The architecture shift that onchain payment routing enables is conceptually straightforward: instead of one collection arriving in a servicer's bank account and then being disbursed sequentially, the collection arrives at a smart contract router that distributes all shares simultaneously, in a single transaction, to every entitled wallet.
This is precisely what shaka.deal is built to do. It is a B2B onchain payment router on Ethereum. The total amount of a collection enters the routing contract, and the contract distributes it instantly to every entitled party at preset shares, in one transaction, with finality. The router never holds the funds — it routes them. There is no custody event, no overnight balance, no counterparty exposure in transit.
For a tokenized invoice pool, this means the distribution waterfall is not a downstream spreadsheet calculation. It is encoded into the deal itself, upstream, when the pool is structured. The servicer does not distribute — the protocol distributes, with the servicer having set the parameters correctly at configuration time.
The transfer is final once confirmed onchain, settles in seconds to minutes depending on the chain, and produces a permanent transaction record that finance teams can reconcile against an invoice or general-ledger entry. That transaction record is not a statement — it is cryptographic proof of simultaneous settlement, visible to every party with a block explorer.
A concrete scenario: a collection event in a $2.8 million (AUD 4.3 million) pool
Consider a mid-market trade finance pool. The pool contains 48 verified invoices from a construction supply business, all with accepted purchase orders from a tier-one building contractor. The invoices are denominated in USD and have tenors between 45 and 90 days. The pool has two investor tiers and a servicer/originator retaining a residual.
The capital structure is as follows:
| Component | Amount | Terms |
|---|---|---|
| Senior tranche | $2.0M (AUD 3.1M) | 7.5% annualised coupon; held by a pension-adjacent credit fund |
| Junior tranche | $600,000 (AUD 921,000) | 14.0% annualised coupon; held by a specialist trade finance manager |
| Originator equity / residual | Approximately $200,000 (AUD 307,000) | Retained by the originator as first-loss coverage and excess spread |
| Reserve account | $50,000 (AUD 77,000) | Prefunded at closing, topped up from each collection to maintain a 2% floor |
| Servicer spread | Basis-point entitlement accruing on outstanding balance | Payable to the servicing entity on each distribution date |
A debtor settles $180,000 (AUD 276,000) in full, marking the close of five invoices. Under the traditional model, the servicer would receive that $180,000 into their collection account, run the waterfall calculation, and dispatch wires over the following 48 to 72 hours. Senior investors and junior investors would see funds at different times. The originator would receive their spread last.
Under an onchain routing model using shaka.deal, the mechanics work differently. The waterfall shares were encoded at pool configuration. The deal preset captures the senior coupon accrual on that slice of the portfolio, the junior coupon accrual, the reserve top-up required to maintain the 2% floor, the servicer spread entitlement, and the residual to the originator's wallet. The moment the $180,000 arrives at the routing contract — which the servicer triggers after confirming the debtor payment — the contract splits and routes simultaneously:
- Senior investor wallet receives their pro-rata principal and coupon component
- Junior investor wallet receives their pro-rata component
- Reserve contract receives its top-up contribution
- Servicer account receives its spread
- Originator residual wallet receives the remainder
All of this happens in one Ethereum transaction. Ethereum L1 confirms in roughly 12 seconds and reaches economic finality in about 12 minutes. Every party can verify their receipt without waiting for a distribution statement to be issued. The transaction hash is the distribution statement.
Encoding the waterfall: what "preset shares" means in practice
The phrase "preset shares" deserves precision, because a tokenized invoice pool waterfall is not a simple percentage split. It is a layered calculation with time-varying components, and encoding it correctly is where the real work sits.
In a static percentage split — say, a deal where Party A receives 60% and Party B receives 40% — the routing contract is set once and never changes. Invoice pool distributions are more dynamic because coupon accruals change as outstanding balances amortize, and the reserve top-up obligation changes as the reserve balance fluctuates relative to the target floor.
There are two main approaches practitioners use:
1. Pre-calculated split, triggered by the servicer. The servicer's calculation engine (or the pool administrator's) runs the waterfall offline, determines the exact dollar amounts for each entitled party on this particular collection, and passes those amounts to the routing contract as parameters at trigger time. The contract executes the split as instructed. The contract guarantees simultaneous delivery and provides the immutable record, but the calculation logic lives off-chain. This approach works well for pools where the waterfall is genuinely complex and the servicer retains calculation responsibility — which is the appropriate structure for most institutional mandates.
2. Fully encoded waterfall. The pool smart contract holds the coupon rate, amortization schedule, reserve target, and servicer spread parameters, and calculates the split at distribution time from oracle-fed data about accrued balances. A smart contract can automatically trigger a payout to investors once the underlying invoice is paid. This automation is key to reducing manual work and potential errors. This approach is more technically demanding but can reduce servicer operational burden on high-volume pools with many small invoices.
In either case, shaka.deal functions as the final execution layer — the entity that, once the correct shares are determined, ensures every party receives their entitlement in the same block, not in sequence.
The role of professionals doesn't shrink — it sharpens
It would be a mistake to read this as a story about automation reducing the need for skilled professionals. The opposite is closer to the truth. What onchain routing removes is the operational exposure of sequential disbursement — the risk that funds sat overnight in a transit account, or that a wire to one party failed while others had already been paid. What it preserves, and actually elevates, is the judgment work that professionals perform before the collection arrives.
The servicer still determines whether a debtor payment is genuine and complete. The pool administrator still monitors concentration limits and eligibility criteria on a daily basis. The originator still underwrites the credit quality of each invoice before it enters the pool. Custodians, compliance frameworks, token classification, and jurisdiction questions all sit behind every credible product, and skipping any of them creates risk that eventually surfaces. Settlement agents working on the legal structure of the SPV vehicle still draft and execute the assignment agreements and investor subscription documents that give the tokens their economic meaning. None of this changes.
What changes is the distribution event itself. Instead of being the moment where things can go wrong — a payment to the wrong account, a day's float unexpectedly sitting in the servicer's balance sheet, a distribution statement that arrives after an investor has already started chasing — it becomes the most reliable part of the entire process.
Transparency is what makes a fractional note saleable and a lender's reputation defensible. When every collection event is visible onchain, every party can audit every distribution without waiting for reports. That transparency is an asset for the servicer and the pool administrator, not a threat.
What happens at partial payment and late payment
Real-world invoice pools are not clean. Some debtors pay partial amounts. Some pay late. Some dispute a portion of an invoice. The routing mechanics need to accommodate these events without requiring a structural reconfiguration each time.
In a partial payment scenario, the servicer receives less than the full invoice face value. Under the preset waterfall, the partial collection is still routed immediately and simultaneously to entitled parties in their respective proportions — it is simply a smaller amount flowing through the same distribution architecture. The outstanding balance on the partially paid invoice remains live in the pool, and the next partial or full collection against that invoice triggers another routing event. The investor does not wait for the invoice to close fully before receiving their proportional share of what has been collected.
In a late payment scenario, the waterfall may need to route a default interest component in addition to regular coupon. If that late payment interest is contractually defined and included in the preset parameters, it routes automatically. If it requires servicer discretion — because a late charge was waived, for example, as part of a debtor relationship management decision — the servicer passes updated parameters at distribution time.
Invoice-based exposures where repayment is linked to buyer settlement. Strong structures include assignment of proceeds, credible obligor checks, and tight servicing and reporting. The "tight servicing and reporting" part is not replaced by automation — it is what makes automation trustworthy.
In default scenarios, where an invoice is unrecoverable, the pool waterfall redirects first to the reserve account, then absorbs losses in the junior tranche before touching the senior. Junior tokens carry variable yield and absorb the first defaults in the portfolio. These loss allocation mechanics can be encoded into the distribution logic, so that when a servicer marks an invoice as a confirmed loss, the reserve drawdown and tranche write-down happen onchain, and every token holder's position updates with full transparency.
Cross-border pools and multi-currency considerations
A significant proportion of invoice pool activity involves cross-border supply chains, where the invoices are denominated in one currency and investors may be in another. Cross-border settlement timing, high FX costs, and delayed finality explain why cross-border B2B has become the leading real-economy stablecoin use case.
In practice, most institutional tokenized invoice pools denominate the pool itself in a single currency — typically USD — and settle distributions in a USD-pegged stablecoin. Investors in AUD, EUR, or other currencies handle their own conversion after receipt. This simplifies the waterfall considerably: the router always disburses one token type, at the correct proportional amount, to each wallet. The FX question is offloaded to each party's own treasury function.
Blockchain networks process and finalize settlement transactions within seconds or minutes. Payment processing continues seamlessly across weekends and national bank holidays. Corporate treasuries can execute high-value supplier payments without adhering to strict banking cut-off windows. This 24/7 availability matters enormously for cross-border pools where debtors in Asia may settle on a Friday local time, which is a Saturday in the investors' jurisdictions. Under traditional rails, that collection would sit unprocessed until Monday. Under an onchain routing model, it distributes to all parties immediately.
The audit trail as a structural advantage
Every collection event through a routing contract produces an immutable transaction record on Ethereum. The hash, the block timestamp, the exact amounts to each address, and the total routed sum are permanently visible. This is not merely a technology feature — it is a structural advantage for the professionals administering the pool.
Fund accountants reconciling the pool's NAV can verify distributions against transaction hashes rather than distribution statements that may arrive days later. Senior investors verifying that the waterfall ran correctly — that they received the right coupon amount before any subordinate distribution occurred — can check the block rather than waiting for a servicer report. Tax accountants working on income recognition can point to an immutable timestamp for each distribution event rather than relying on bank value dates.
The strongest investor argument for tokenization is not hype around blockchain. It is operational clarity paired with regulated access. When the issuance structure is compliant and the asset base is real, tokenization can bring tangible benefits.
The combination of a correctly structured legal SPV, verified invoice assets, and onchain distribution routing via shaka.deal produces a pool where the legal clarity and the operational clarity are aligned. Every party knows their entitlement before the collection arrives. Every party receives it simultaneously when the collection is routed. And every party can verify their receipt independently, in real time, without waiting for anyone else.
Structuring for onchain distribution: a checklist for advisers
For settlement agents, fund counsel, and pool administrators working on a tokenized invoice facility that will route distributions onchain, the following structural considerations apply at setup time:
Wallet infrastructure for each entitled party. Every party must hold a wallet address before the pool opens. For institutional investors this typically means a custody wallet from a regulated custodian. The address is recorded in the pool's distribution parameters and is as material as a bank account number in a traditional structure.
Stablecoin denomination of distributions. Confirm the distribution currency before encoding the waterfall. USDC is the most commonly used stablecoin for institutional trade finance pools on Ethereum, though the specific instrument should be agreed in the investor subscription documents.
Waterfall parameter review. The preset shares — whether expressed as percentages of each collection, or as prioritized tiers with a residual — must be reviewed by deal counsel and confirmed by the pool administrator before any distribution is triggered. An error in the waterfall parameters is far harder to remediate after an onchain distribution than before.
Servicer trigger authority. Document clearly which entity has authority to trigger the distribution routing contract, and what confirmations they must hold before doing so (confirmation of debtor payment cleared, invoice matched, no dispute flag). This is a governance question, not a technology question.
Reconciliation protocol. Agree upfront how fund accountants will reconcile onchain distribution events against the pool's NAV model, particularly for partial collections and late payment interest.
Closing: the collection moment should be the simplest moment
In a well-run tokenized invoice pool, enormous care and expertise are invested in the origination and structuring phase: credit underwriting, legal documentation, regulatory analysis, investor onboarding. That work deserves an execution layer that does not introduce friction or uncertainty when it finally pays off — literally.
The collection moment is when the structure proves its value. An investor who funded a cross-border supply chain pool at six in the morning should receive their distribution in the same Ethereum block as every other entitled party, regardless of time zones, banking cut-off windows, or how many wires the servicer had in their outbox that day.
That is what shaka.deal provides: one incoming collection, preset shares, simultaneous payout, and a final settlement record that every professional in the deal can read without asking anyone else. The waterfall runs. The funds route. The deal is done.
