Transactions, Ledgers,
and Double-Entry Accounting

In Chapter 1, we learned that a payment is a process. In Chapter 2, we go one level deeper: once a payment is processed, how does a payment business keep track of who owns the money, what has been settled, what is still owed, and whether the books match the processor and the bank? The answer starts with ledgers and double-entry accounting.

At the end of Chapter 1, Emma bought a pair of shoes from Urban Shoes.

She paid:

$100.00

After underlying payment costs, the processor settled:

$97.50

ShopPlatform charged Urban Shoes:

$1.00

So:

Urban Shoes owns $96.50

and

ShopPlatform owns $1.00

One customer payment has now created several different financial facts.

Our payment system must be able to answer a deceptively simple question:

“

Whose money is it?

This question is the reason payment platforms need a ledger.

1. A Transaction Is Not a Balance

Our payment database contains:

Transaction ID: TX-10001 Merchant: Urban Shoes Gross Amount: $100.00 Status: Captured

This tells us something important happened.

But it does not tell us everything.

For example, it does not tell us:

How much money will the processor actually settle?

How much belongs to Urban Shoes?

How much belongs to ShopPlatform?

How much was consumed by payment costs?

Has the merchant already been paid?

Is some money being held?

Was part of the transaction refunded?

A transaction describes an event.

A balance describes a financial position.

These are related concepts, but they are not the same.

2. Why Not Just Store merchant_balance = 96.50?

Imagine a developer proposes a simple solution:

Urban Shoes
Balance: $96.50

At first, this seems reasonable.

Tomorrow another customer pays $200.

The developer changes the balance:

Balance: $289.50

Then Urban Shoes receives a $100 payout:

Balance: $189.50

Then there is a $30 refund:

Balance: $159.50

Now Finance asks:

“

“Why is the balance $159.50?”

We have a problem.

We know the current number.

But we have lost the story behind the number.

A financial system needs to answer:

“

What increased the balance?

“

What decreased it?

“

When?

“

Which transaction caused the change?

“

Which fee was applied?

“

Was anything reversed?

“

Who authorized the operation?

“

Can we reconstruct the balance from the underlying records?

This is why professional financial systems do not treat a balance as just a number that developers repeatedly overwrite.

They maintain a history of financial entries.

That history is the foundation of a ledger.

3. What Is a Ledger?

A ledger is a structured record of financial activity.

Instead of storing only:

Current balance = $159.50

we store the events that created that balance.

For example:

Now the balance is not mysterious.

We can reconstruct it:

$96.50 + $193.00 − $100.00 − $30.00 = $159.50

This gives us one of the most important principles in financial software:

“

A balance should be explainable by the entries that created it.

4. But One Ledger Is Still Not Enough

There is another problem.

Remember TX-10001.

Emma paid:

$100.00

The processor settles:

$97.50

Urban Shoes owns:

$96.50

ShopPlatform owns:

$1.00

We cannot put all these numbers into one balance.

They represent different things.

We therefore need separate ledger accounts.

Think of a ledger account as a financial bucket with a specific meaning.

For our simplified example, we might have:

Processor Settlement / Cash

Money received or expected from the processor.

Merchant Payable — Urban Shoes

Money the platform owes Urban Shoes.

Platform Revenue

Money earned by ShopPlatform.

Later we may introduce many more accounts:

Processing Fees

Merchant Reserve

Refunds

Chargebacks

Payouts

Bank Cash

Processor Receivable

and others.

The exact account structure depends on the payment business and accounting design.

But the principle is universal:

“

Different financial meanings must be tracked separately.

5. Assets, Liabilities, Revenue, and Expenses

Before we can understand double-entry accounting, we need four basic concepts.

Do not worry — you do not need to become an accountant.

Asset

Something the company owns or controls that has economic value.

Examples:

Cash in a bank account

Money receivable from a processor

Liability

Something the company owes to someone else.

If ShopPlatform is holding $96.50 that belongs to Urban Shoes, that money is not ShopPlatform's revenue.

It represents an obligation.

We can call it:

Merchant Payable

That is a liability.

Revenue

Money the company earns from providing its services.

If ShopPlatform earns a $1 platform fee:

Platform Revenue = $1.00

Expense

A cost incurred by the business.

For example, depending on the commercial and accounting structure, processing costs charged to the platform may be recorded as an expense.

For now, remember:

Asset = what we have or are owed

Liability = what we owe

Revenue = what we earn

Expense = what it costs us

6. The Most Important Distinction in Payment Accounting

ShopPlatform receives:

$97.50

Does ShopPlatform have $97.50 of revenue?

Absolutely not.

Only:

$1.00

belongs economically to ShopPlatform in our example.

The other:

$96.50

belongs to Urban Shoes.

This is one of the most important concepts in payments.

“

Money passing through your platform is not necessarily your money.

A company can process billions of dollars while earning only a small percentage of that volume as revenue.

This is why payment volume and revenue are completely different metrics.

7. The Accounting Equation

Traditional accounting is built around a simple relationship:

Assets = Liabilities + Equity

Revenue and expenses ultimately affect equity, but for our payment examples we will focus on the practical behavior of individual accounts.

The important principle is that the financial system must remain balanced.

This leads us to:

Double-Entry Accounting

Every accounting event affects at least two accounts.

And:

“

Total Debits must always equal Total Credits.

8. What Are Debit and Credit?

The words Debit and Credit confuse almost every beginner because everyday banking uses these words differently.

For this course, forget:

“

“Debit means money out.”

and

“

“Credit means money in.”

Those rules are wrong.

Debit and Credit are simply the two sides of an accounting entry.

Different account types increase on different sides.

A simplified reference is:

You do not need to memorize this immediately.

We will learn it through transactions.

9. Our First Double-Entry

The processor sends ShopPlatform:

$97.50

ShopPlatform now has an asset:

Cash: $97.50

But that money has two economic owners.

Urban Shoes is owed:

$96.50

ShopPlatform earned:

$1.00

Our simplified accounting entry is:

Dr Cash / Processor Settlement        $97.50

    Cr Merchant Payable               $96.50
    Cr Platform Revenue                $1.00

Now calculate both sides.

Debits: $97.50

Credits: $96.50 + $1.00 = $97.50

Therefore:

Debits = Credits

The entry balances.

10. What Did This Entry Actually Say?

The accounting entry is simply a structured sentence.

It says:

“

“We received $97.50 of value. Of that amount, we owe Urban Shoes $96.50, and we earned $1.00.”

That is all double-entry accounting is doing.

It is forcing the financial system to explain both sides of the event.

Without double-entry, a developer might write:

cash += 97.50

But then we know only that cash increased.

We do not know why.

With double-entry:

Cash                    +97.50
Merchant obligation     +96.50
Platform revenue         +1.00

the system explains the complete financial meaning.

11. Why Must Debit Equal Credit?

Imagine a developer accidentally creates:

Dr Cash                         $97.50

    Cr Merchant Payable         $96.50

Something is missing.

Debits:

$97.50

Credits:

$96.50

Difference:

$1.00

The entry does not balance.

That tells us immediately:

“

Something is wrong.

Perhaps the $1 platform revenue was forgotten.

This is one of the great strengths of double-entry accounting.

The system contains an internal mathematical consistency check.

It does not guarantee that every business decision is correct.

But it makes many classes of financial errors easier to detect.

12. Transaction vs Ledger Entry

Now we can make a very important distinction.

Transaction

TX-10001 tells us:

“

Emma made a $100 purchase at Urban Shoes.

Ledger Entries

The ledger tells us:

“

What financial effects resulted from that transaction?

One transaction may therefore generate multiple ledger entries.

Conceptually:

TX-10001
Customer Payment: $100
        │
        ▼
Financial Calculation
        │
        ├── Processor costs
        ├── Merchant amount
        └── Platform fee
                │
                ▼
             Ledger

This distinction becomes critical in sophisticated payment platforms.

13. Gross Amount, Net Amount, and Revenue

Let's make sure these concepts are completely clear.

Emma paid:

Gross Transaction Amount = $100.00

Underlying payment costs:

$2.50

Processor settlement:

$97.50

Platform fee:

$1.00

Merchant payable:

$96.50

Platform revenue:

$1.00

These numbers describe different financial facts.

Do not confuse:

$100 Gross Payment Volume

with

$97.50 Settlement

with

$96.50 Merchant Payable

with

$1.00 Platform Revenue

They all originate from the same customer purchase.

But they are not interchangeable.

14. Now Pay the Merchant

Urban Shoes has:

Merchant Payable = $96.50

Eventually ShopPlatform sends the money to Urban Shoes' bank account.

This is the payout.

Before payout:

Cash                     $97.50
Merchant Payable         $96.50
Platform Revenue          $1.00

Now ShopPlatform pays:

$96.50

to Urban Shoes.

The accounting entry becomes:

Dr Merchant Payable              $96.50

    Cr Cash                       $96.50

What happened?

The platform's cash decreased.

But its obligation to Urban Shoes also disappeared.

15. After the Payout

Before payout:

Cash: $97.50

Merchant Payable: $96.50

After payout:

Cash: $1.00

Merchant Payable: $0.00

The remaining:

$1.00

corresponds to the platform's revenue in our simplified example.

This is another important lesson:

“

Payout does not create the merchant's money.

The platform already owed the merchant that money.

Payout simply settles the obligation.

16. Pending, Available, and Paid Are Different

Real payment platforms usually need more than one concept of merchant balance.

Imagine TX-10001 has been captured but the processor has not yet settled it.

Should Urban Shoes immediately be allowed to withdraw $96.50?

Maybe.

Maybe not.

That depends on the platform's risk and payout model.

This leads to concepts such as:

Pending Balance

Money associated with transactions that is not yet available for payout.

Available Balance

Money the merchant can currently receive.

Reserve Balance

Money intentionally held back for risk management.

Paid / Payout Amount

Money already sent to the merchant.

These balances answer different questions.

17. Example: Pending Becomes Available

Suppose TX-10001 is captured today.

The system calculates:

Merchant amount: $96.50

Initially:

Pending Merchant Balance      $96.50
Available Merchant Balance     $0.00

After settlement and the platform's release rules are satisfied:

Pending Merchant Balance       $0.00
Available Merchant Balance    $96.50

Nothing new was sold.

The economic ownership did not suddenly appear.

The state of the money changed.

This distinction is extremely important in PayFac systems.

18. Reserves

Now imagine Urban Shoes is considered a higher-risk merchant.

ShopPlatform decides to hold:

10% reserve

from the merchant's $96.50.

Reserve:

$9.65

Immediately available:

$86.85

So:

Merchant Payable               $96.50

Available                      $86.85
Reserve                         $9.65
                               ------
Total                           $96.50

The platform does not earn the $9.65 reserve.

The money still belongs economically to the merchant under the applicable arrangement, but it is temporarily unavailable for payout.

This distinction matters.

“

Held money is not necessarily revenue.

19. Why Do Payment Platforms Hold Reserves?

Imagine Urban Shoes suddenly stops trading.

But customers continue filing chargebacks.

Who will cover those financial obligations?

The payment platform may still be exposed.

Reserves can help manage that risk.

Depending on the business model, risk rules, processor requirements, and merchant agreement, a platform might use:

rolling reserves,

fixed reserves,

minimum balances,

or other risk mechanisms.

For now, understand the basic purpose:

“

A reserve keeps some merchant funds available to absorb future financial risk.

20. Refunds

Now Emma decides that the shoes are the wrong size.

Urban Shoes gives her a:

$30 refund

What happens?

The original $100 transaction does not simply become:

$70 transaction

The original transaction happened.

The refund is a new financial event linked to the original transaction.

Conceptually:

TX-10001
SALE
$100
   │
   └── RF-10001
       REFUND
       $30

This is important for auditability.

We want to preserve the original history.

21. Why We Do Not Rewrite History

Imagine we simply change:

Original Sale: $100

to:

Original Sale: $70

Now someone reviewing the system next month may think Emma originally purchased $70 of goods.

That is false.

She purchased:

$100

and later received:

$30 back.

Financial systems should preserve this distinction.

Therefore:

“

Do not rewrite financial history when a new financial event occurs.

Record the new event.

22. Ledger Entries Should Be Append-Only

This leads to another important engineering principle.

A well-designed financial ledger is generally treated as append-only.

Instead of modifying or deleting old financial entries, we create new entries that reverse or adjust them.

Why?

Because we need an audit trail.

Suppose an entry was wrong.

Rather than silently changing yesterday's record, we can create:

Reversal Entry

followed by:

Correct Entry

Now the history remains visible.

We know:

what happened,

what was wrong,

how it was corrected,

and when.

This is essential in financial infrastructure.

23. Chargebacks Are Not Refunds

Now imagine a different scenario.

Emma does not contact Urban Shoes.

Instead, she disputes the $100 card transaction with her bank.

This can begin a chargeback/dispute process.

A chargeback is not simply another name for a refund.

Refund

The merchant or platform voluntarily returns money to the customer.

Chargeback

The cardholder disputes the transaction through the card-payment ecosystem, and the dispute process can cause funds to be debited back through the payment chain.

The financial impact may include:

transaction amount,

chargeback fee,

and potentially other adjustments.

24. Why Chargebacks Matter to PayFacs

Imagine ShopPlatform supports:

20,000 merchants

and processes:

$2 billion annually.

A small percentage of merchants may generate unusually high levels of disputes.

If ShopPlatform is operating under a PayFac model, merchant risk becomes extremely important.

It must understand:

Which merchants generate chargebacks?

How much money is exposed?

Are reserves sufficient?

Should payouts be delayed?

Should the merchant be reviewed?

Should processing be restricted?

This is why payment infrastructure connects:

Transactions

with

Risk

with

Balances

with

Reserves

with

Payouts

with

Ledger accounting.

These are not isolated systems.

25. Reconciliation: Does Reality Match the Ledger?

Now we reach another critical concept.

Our ledger says:

“

“The processor should send us $97.50.”

The processor's settlement report says:

$97.50

The bank shows:

$97.50 received

Excellent.

The records match.

This is reconciliation.

Conceptually:

Internal Ledger
      $97.50
         │
         ▼
Processor Settlement Report
      $97.50
         │
         ▼
Bank
      $97.50

Everything agrees.

26. What If They Do Not Match?

Suppose our ledger expects:

$97.50

The processor report shows:

$97.20

And the bank receives:

$97.20

Now we have:

Expected: $97.50

Actual: $97.20

Difference: $0.30

Something needs investigation.

Perhaps:

a fee was not recorded,

a pricing rule was wrong,

the processor applied an adjustment,

a transaction was missing,

or our internal calculation was incorrect.

The important point is:

“

The ledger tells us what we believe should have happened. Reconciliation compares that belief with external financial reality.

27. Why Reconciliation Is Essential

Imagine processing:

10 million transactions per month.

A difference of only:

$0.10 per transaction

could theoretically represent:

$1,000,000

of unexplained difference.

Small errors become large problems at payment scale.

That is why reconciliation is not an optional finance feature.

It is part of the control system of a payment business.

28. One Payment Now Has Several IDs

Another important practical detail:

Emma thinks there is one purchase.

But internally we may have:

Order ID
ORD-5001

Transaction ID
TX-10001

Processor Transaction ID
proc_847293

Settlement ID
SET-8001

Payout ID
PO-9001

Refund ID
RF-10001

Chargeback ID
CHB-3001

These records are connected.

But they represent different events.

A sophisticated payment platform must maintain those relationships.

This is why payment data models quickly become more complex than ordinary e-commerce databases.

29. The Payment Platform's View

Let's now look at Emma's transaction as a payment platform might.

Customer Layer

Emma paid:

$100.00

Transaction Layer

TX-10001
Sale
$100.00
Captured

Processing Layer

Gross                 $100.00
Underlying costs       -$2.50
Processor settlement   $97.50

Platform Economics

Platform fee            $1.00
Merchant amount        $96.50

Ledger Layer

Cash / Settlement      +$97.50

Merchant Payable       +$96.50
Platform Revenue        +$1.00

Payout Layer

Merchant Payout        -$96.50

Final Simplified Position

Merchant Payable         $0.00
Platform Revenue          $1.00

This is the financial anatomy of what the customer experienced as:

Click → Pay → Success

30. Why This Matters for PSP, PayFac, and MoR

We can now return to the business models from the introduction.

PSP

A merchant may primarily rely on its PSP to perform much of the payment processing infrastructure.

The merchant sees transactions, fees, settlements, and payouts.

PayFac

A PayFac has a much more complicated problem.

It may need to maintain financial positions across:

thousands of sub-merchants,

multiple processors,

different pricing agreements,

reserves,

payout schedules,

refunds,

chargebacks,

and settlements.

Knowing exactly who owns each dollar becomes a core platform responsibility.

Merchant of Record

An MoR has an even broader financial responsibility around the covered commercial transaction.

It may need to account for:

customer payments,

seller obligations,

taxes,

refunds,

chargebacks,

fees,

FX,

settlements,

and payouts.

As operational responsibility increases, the importance of accurate ledger infrastructure increases with it.

31. Where Amaryllis Fits

This is one of the areas where the role of Amaryllis becomes easier to understand.

A growing payment business does not merely need an API that says:

Payment successful.

It needs an operating layer capable of understanding the complete financial lifecycle.

Conceptually:

                    AMARYLLIS

Merchant Onboarding
        │
        ▼
Transactions
        │
        ▼
Pricing & Fees
        │
        ▼
Balances / Ledger
        │
        ├── Available
        ├── Pending
        └── Reserve
        │
        ▼
Settlement
        │
        ▼
Payout
        │
        ▼
Reconciliation

Risk ──────────────────────────┐
Compliance ────────────────────┤
Disputes / Chargebacks ────────┤
Reporting ─────────────────────┘

Underlying processors may actually move payment messages and funds.

But the payment business still needs to understand and control:

“

What happened?

“

Who owns the money?

“

What fees apply?

“

What can be paid out?

“

What must be reserved?

“

What do we owe?

“

What did we earn?

“

Does our internal financial state match our processors and banks?

This is the layer where platforms such as Amaryllis become critical.

32. The Five Concepts You Must Never Confuse

By now, five terms should have very different meanings in your mind.

Transaction

What happened?

Example:

“

Emma purchased $100 of shoes.

Ledger Entry

What financial effect did it create?

Example:

“

The platform owes Urban Shoes $96.50.

Balance

What is the current financial position?

Example:

“

Urban Shoes currently has $96.50 available.

Settlement

What funds were settled through the payment infrastructure?

Example:

“

The processor settled $97.50.

Reconciliation

Does our internal financial record match external reality?

Example:

“

Ledger = $97.50 Processor report = $97.50 Bank = $97.50

Match.

These concepts are related.

They are not interchangeable.

33. One Final Example

Suppose tomorrow Urban Shoes processes another:

$200 sale

After underlying costs:

Processor settlement = $195

Platform fee:

$2

Merchant amount:

$193

Before any payout, the merchant already has:

$96.50

from TX-10001.

Now add:

$193.00

from TX-10002.

Merchant Payable becomes:

$289.50

Then ShopPlatform sends a payout:

$250

Merchant Payable becomes:

$39.50

The merchant's bank receives:

$250

but the merchant still has:

$39.50

owed by the platform.

This is why:

“

Payout amount and merchant balance are not the same thing.

34. Think Like a Payment Engineer

When you see:

Transaction: $100

do not think:

“

“There is $100.”

Instead, start asking:

“

Was it authorized?

“

Was it captured?

“

Was it settled?

“

What fees apply?

“

What is the merchant's net amount?

“

Has the platform earned a fee?

“

Is the merchant amount pending or available?

“

Is any amount reserved?

“

Has it been paid out?

“

Has it been refunded?

“

Is there a chargeback?

“

What does the ledger say?

“

Does the ledger reconcile with the processor?

“

Does the processor reconcile with the bank?

That way of thinking is one of the major differences between building an ordinary web application and building payment infrastructure.

35. What You Should Know After This Chapter

You should now understand that:

A transaction records a payment-related event.

A ledger records the financial consequences of events.

A balance is produced from financial entries and represents a financial position.

Money held for a merchant is not automatically platform revenue.

Debit and Credit are accounting directions, not synonyms for money leaving or entering a bank account.

Every double-entry accounting event must balance:

Total Debits = Total Credits

Merchant money can move through different states:

Pending → Available → Reserved → Paid

A refund is a new financial event rather than a rewrite of the original sale.

A chargeback is different from a refund.

Settlement and payout are different events.

And reconciliation verifies that our internal financial records agree with external processor and banking records.

Most importantly:

“

A payment platform must always be able to explain who owns every dollar, why they own it, where that dollar is now, and how it got there.

That is the purpose of the ledger.

Next: Practical Exercise 2 — Build the Ledger Yourself

You are going to become the payment system.

Starting with Emma's:

$100 purchase

you will create the ledger entries yourself.

Then we will make the scenario progressively more difficult:

Sale

↓

Platform Fee

↓

Settlement

↓

Merchant Balance

↓

10% Reserve

↓

Payout

↓

$30 Refund

↓

Chargeback

↓

Reconciliation Difference

For every event, you will have to answer four questions:

1. What happened?

2. Which accounts changed?

3. Which side is Debit and which is Credit?

4. Do Total Debits still equal Total Credits?

If they do not, something is wrong.

Welcome to the part of payments where every cent has to have an explanation.