| TL;DR: A marketplace payment may clear in seconds, but the business still has to track seller payouts, fees, commissions, and possible refunds across several systems. SDK.finance’s new real-time ledger is designed to record those changes alongside an existing payment system, without requiring the business to replace it. The launch reflects a growing accounting challenge as payments happen faster and financial products connect to more systems: keeping an accurate account of who is owed what as each transaction changes. |
A customer pays for an order on a marketplace. The payment succeeds in seconds. Behind that confirmation, the marketplace owes the seller a payout and keeps a commission after covering a processing fee. If the customer later receives a refund, some of those amounts may need to change again.
Each step affects what the seller is owed and what the marketplace keeps, sometimes long after the customer has closed the app. So, while the payment may look finished, the accounting work is not.
SDK.finance’s newly launched Real-Time Ledger is designed to add an accounting layer without replacing the systems that process payments. The bigger question is whether those records stay accurate when a payment, payout, or refund passes through several systems.
Faster Payments Raise the Stakes for the Systems Behind Them
Payment networks have spent years reducing the time it takes to move money. In the US, FedNow settled nearly 5 million payments in the second quarter of 2026, an 83% increase from the previous quarter. In Europe, rules requiring many payment providers to offer instant euro transfers are being introduced in stages.
As payments become available around the clock, another question becomes more important: how quickly can a business see how each payment affects its accounts?
And that becomes harder as a company adds new products and works with more payment providers. A wallet might show a customer’s available balance while recording a pending transfer. A payment platform might need to track fees and settlement amounts across several providers. A marketplace must know what belongs to the seller even when the money has not yet been paid out.
Liudmyla Kozachok, Head of Marketing at SDK.finance, put the marketplace problem simply:

After all, the payment going through is only part of the picture. The business still needs to track how it affects each account.
Replacing A Live System Can Create Another Problem
Banks and fintech companies already have ledgers in some form. The challenge is often keeping those ledger records connected to the systems that process daily transactions.
A business may have built its payment workflows over several years. These workflows can connect its banking platform and payment providers with internal reporting tools. That means changing one part of the setup can affect a lot more than the accounting team.
Replacing the transaction system to improve accounting would affect more than the finance team. Engineers would have to move integrations and retest every flow while keeping a live product running. In other words, improving the accounting layer does not necessarily mean replacing the system that moves the money.
SDK.finance has taken a more contained approach. Its new ledger for banks and fintechs is a standalone module designed to sit alongside an existing system. According to the company, it applies accounting rules to transactions and other payment events, then records matching debit and credit entries to keep the accounts balanced. It also updates account balances and retains a history of the entries.
The existing system continues to handle the customer’s payment. The added ledger records how that payment affects the business’s accounts.
Kozachok says the integration is configured on the ledger side, so the company can preserve its existing workflows. That sounds simple on paper. In practice, though, the integration work still depends on how the company’s existing payment systems are built.
A Separate Ledger Still Needs the Full Story
For the ledger to produce accurate records, it needs the right transaction information and rules for handling it. Take the marketplace order example again. The accounting rules have to distinguish the seller’s share from the platform’s commission. They also need to account for processing fees, along with any payout or refund that follows.
And this is where things can get complicated. If the transaction system and payment accounting software show different records, someone needs to determine which record is correct and why they differ.
SDK.finance says posted entries cannot simply be edited. Corrections use reversing entries rather than changing the original record. That approach preserves the original entry alongside the correction, which can make the sequence of changes easier to audit.
Still, a real-time ledger does not remove the need to check those records against other systems. A business can record transactions faster and still need to check its records against those held by banks and payment providers. Real-time accounting may help teams spot differences sooner. It does not, by itself, prove that every outside record agrees.
This is especially relevant as companies add financial features to products that were not originally built for financial services. Kozachok says that responsibility continues long after the feature goes live. She says:

The Real Choice is About Control, Not Speed
SDK.finance is entering a field where other companies already offer real-time ledgers. Modern Treasury launched an independent, double-entry ledger in 2021. Formance offers a ledger that can run as a standalone service.
The comparison comes down to how each approach fits the systems a customer already uses and how much control the customer wants over changes and updates to the software.
SDK.finance offers both SaaS and source-code licensing. Kozachok says source-code access is useful for organizations that want to modify the software and decide when to release those changes. In practice, though, that also means taking on the work of maintaining and operating the software. For a company without enough engineers, that flexibility may be less useful.
Regulatory changes can also require updates to the system. Kozachok says some changes, such as transaction thresholds, may be handled by adjusting the software’s settings. New reporting or onboarding requirements may require development and testing. Either way, the business still has to work out what it needs to comply with and make sure the system reflects those requirements.
These challenges are becoming more common as financial products connect to more systems and payment networks. After all, the systems behind those products may need to work reliably for years. Their records also need to hold up when something goes wrong.
And that is where the choice gets less simple. Speed alone won’t settle it. A ledger can record transactions in real time, but businesses still need to know they can trust those records and keep the system running years from now.




