Chapter 1. How payments show up in the books.

An electronic payment is never a single accounting event. It is a chain of successive events. The sale is earned at the register, but the money reaches the bank one to seven days later, minus fees, and a dispute can still claw it back. In between, the receivable changes form several times. Accounting for payment collection means recording each of those intermediate states faithfully. That is what separates a clean trial balance from a 471 account that keeps growing until no one can audit it.

From sale to balance sheet: each step is an accounting event

Customer

pays €120 by card

Triggering event: the sale is earned → revenue (707) and output VAT (44571), whatever happens to the funds

Card terminal / PSP

captures the transaction

The receivable changes form: it becomes an item in course of collection (5115) or a balance held by the PSP (467)

Acquirer

settles the batch at D+1 (business day)

The net amount lands in the bank (512) and the fee is expensed (627), never deducted from revenue

Accountant

reconciles, matches, supports

The sales journal, the PSP statement, and the bank statement must tell exactly the same story

🧾

The sale is the triggering event

Under accrual accounting, revenue is recognized when the goods are delivered or the service is performed, not when the cash comes in. The timing gap shows up in receivable accounts, never as a deferred sale.

⏳

The receivable in transit

Between the card receipt and the bank credit, the money exists but is not yet in the bank. It sits in 5115 (card receipts in transit) or in 467 (PSP balance). These accounts are how the books show funds in transit.

✂️

Gross, always gross

The PSP pays out an amount net of fees, but you record the gross revenue and expense the fees (627). Recording the net understates both revenue and expenses. The two errors cancel out in net income, but they distort everything else.

D+1 (business day)

typical settlement time for a card batch with a French bank acquirer (up to D+7 at some PSPs early in the relationship)

0,053 %

card payment fraud rate in France in 2023, or €496 million, and every case becomes a dispute that ends up in the books

OSMP, 2024 annual report

100 %

of balances in suspense account 471 must be supported and cleared at every close. No exceptions

🔑

Three questions to ask every time

Faced with any payment flow, ask the same three questions. First, location: where is the money (register, in transit, at the PSP, at the bank)? Second, ownership: who does it belong to (the company, a customer being refunded, a third-party seller)? Third, cost: what did it cost (fees, dispute fees)? Each answer points to an account. If you cannot answer, the flow goes to 471, temporarily, and only temporarily.

🎯 Quick question

At month-end, should a card sale processed on the terminal but not yet credited to the bank account appear in the books?

Chapter 2. The payment accounts: 511, 471, 580, and related accounts.

The French chart of accounts (plan comptable général, PCG) has everything you need to record the life of a payment, as long as each account is used for its intended purpose. Three of them account for most of the errors. 511 (items in course of collection) is often skipped in favor of posting to 512 too early, and 471 (suspense account) easily becomes a catch-all. 580 (internal transfers) gets forgotten, which creates duplicate entries across cash journals.

Account	Requirement	Payment use	Watch out for
512	Banks	Actual credit to the bank account (net amount paid out)	Never post a flow here before it is credited
5112	Checks for deposit	Checks deposited, not yet credited	Track returned checks that come back to 411/416
5115	Card receipts in transit	Captured card batches awaiting settlement	Balance = funds in transit; reconcile with the terminal batches
467	Other receivables and payables	Merchant balance at a PSP (Stripe, Adyen...), funds to be paid out	One sub-account per PSP and per currency; match every entry
471	Suspense accounts	Unidentified incoming flows awaiting posting	Support line by line and clear before every close
580	Internal transfers	Transit between two cash journals (register → bank)	Must always be at zero; a balance means a flow has been lost
627	Bank and similar services	Payment processing fees, dispute fees, account fees	Separate VAT-exempt fees from taxable fees
6135	Equipment rental	Card terminal rental	20% VAT recoverable; do not confuse with 627
654 / 416	Bad debt losses / Doubtful accounts	Lost chargebacks, final or disputed unpaid amounts	Loss excl. VAT; VAT recoverable under conditions (CGI art. 272)
44571 / 44566	Output VAT / Input VAT	VAT on sales; VAT on fees when charged	Never assume VAT on payment fees: read the invoice

Accounts in the payment collection chain (PCG)

⚠️

Account 471 is not a junk drawer

The suspense account is legitimate but temporary. It holds a flow only as long as it takes to identify it. A 471 carrying balances that are months old is a red flag for the statutory auditor and the tax authority alike. Those balances may hide unreported revenue or third-party funds that were never passed on. At the close, every line must be supported, posted to the right account, or refunded.

Create one 467 sub-account per PSP and per currency (467STRIPE-EUR, 467ADYEN-USD...): matching becomes trivial and discrepancies jump out.
Break 5115 down by terminal or by acquiring contract if you have several points of sale, so you can reconcile batch by batch.
Reserve 580 for movements between your own cash accounts (a cash deposit at the bank, a transfer between accounts): debit 580 / credit 530 in the cash journal, then debit 512 / credit 580 in the bank journal.
Document a rule for clearing 471: any flow still unidentified after 30 days triggers an active search (transfer reference, contacting the PSP), and no balance goes through the close without supporting documents.

🎯 Quick question

A €950 transfer arrives in the bank account with no identifiable reference. Where do you record it until you identify it?

Chapter 3. Standard entries: card sale, PSP fees, refund.

Two setups dominate in practice. In store, with a bank acquiring contract, the terminal sends its batches directly to the bank, the flow goes through 5115, and settlement arrives at D+1 (business day). Online, through a PSP (Stripe, Adyen, PayPal...), receipts build up in a merchant balance (467) and are paid out in periodic payouts, net of fees. The entries differ, but the logic is the same: gross revenue, a receivable in transit, and fees as an expense.

Case 1, an in-store card sale: €120 including VAT (20% VAT), 0.60% acquirer fee

--- Sales journal, 2026-07-11 ------------------------------------
5115   Card receipts in transit           120.00
         707    Merchandise sales                    100.00
         44571  Output VAT (20%)                      20.00

--- Bank journal, 2026-07-13 (settlement at D+1 business day) ----
512    Bank                               119.28
627    Bank services (0.60%)                0.72
         5115   Card receipts in transit             120.00

With a PSP, account 467 acts as an “intermediate bank.” It receives the notified payments, absorbs refunds and disputes, and empties at each payout. The PSP statement (balance report) is the supporting document for all these entries, and you reconcile it line by line against the journal.

Case 2, one week of e-commerce through a PSP: €1,000 in sales, €23.45 in fees, €976.55 payout

--- As orders come in: each order (example: €250) ----------------
411    Customer                           250.00
         707    Sales                                208.33
         44571  Output VAT                            41.67

--- When the PSP notifies the collected payment ------------------
467    PSP account                        250.00
         411    Customer                             250.00

--- On the weekly payout -----------------------------------------
512    Bank                               976.55
627    PSP fees (per statement/invoice)    23.45
         467    PSP account                        1,000.00

🔑

Never book the net as revenue

It is tempting to post “debit 512 / credit 707” for the payout amount. That entry is wrong twice over. Revenue is understated by the fees (a tax risk, distorted ratios), and the bank charges disappear from the income statement. The golden rule never changes: revenue at gross, fees in 627, and 467 as the bridge.

Case 3, a €60 customer refund through the PSP (credit note + cash flow)

--- Credit note: (partial) cancellation of the sale --------------
707    Sales                               50.00
44571  Output VAT                          10.00
         411    Customer                              60.00

--- PSP executes the refund --------------------------------------
411    Customer                            60.00
         467    PSP account                           60.00

Event	Debit	Credit
Card sale (terminal)	5115 (incl. VAT)	707 (excl. VAT) + 44571 (VAT)
Batch settlement	512 (net) + 627 (fees)	5115 (incl. VAT)
Online sale	411 (incl. VAT)	707 (excl. VAT) + 44571 (VAT)
Payment notified by PSP	467	411
PSP payout	512 (net) + 627 (fees)	467 (gross)
Refund (credit note)	707 + 44571	411
Refund (cash flow)	411	467
Cash deposit at the bank	580, then 512	530, then 580

Summary of standard entries

🎯 Quick question

The PSP's monthly statement shows €2,000 in sales collected, €46 in fees, and a €1,954 payout. How do you treat the €46?

Chapter 4. Chargebacks and unpaid amounts: accounting for disputes.

A chargeback is the card networks' dispute mechanism. The cardholder disputes a charge with their bank, which pulls the funds back from the merchant through the acquirer until the dispute is resolved. In the books, the event plays out in several stages. The PSP first takes the funds back from your balance, then charges a dispute fee. Last comes the outcome: either the funds come back (representment won) or the loss becomes final.

Cardholder dispute

The customer disputes the charge with their issuing bank (alleged fraud, goods not received, unrecognized transaction...).

D+2 to D+7

Merchant debited

The acquirer or PSP takes the amount back from the merchant balance and charges a dispute fee (€15 to €50 depending on the provider, as of mid-2026).

D+7 to D+45

Representment

The merchant submits evidence (delivery, 3-D Secure, correspondence with the customer) within the deadline set by the network.

D+30 to D+90

Dispute outcome

Funds are returned if the representment succeeds; otherwise the loss is final, possibly after pre-arbitration or arbitration by the network.

Entries for a €120 chargeback including VAT (20% VAT) + €15 dispute fee

--- On notification: the PSP debits your balance -----------------
411    Customer (receivable reinstated)   120.00
         467    PSP account                          120.00
627    Dispute fee (chargeback fee)        15.00
         467    PSP account                           15.00

--- Favorable outcome: representment won -------------------------
467    PSP account                        120.00
         411    Customer                             120.00

--- Unfavorable outcome: dispute lost ----------------------------
654    Losses on bad debts                100.00
44571  Output VAT (recov., CGI art. 272)   20.00
         411    Customer                             120.00

⚠️

Book the loss neither too early nor too late

While the dispute is open, the right picture is a reinstated customer receivable (411), reclassified to 416, “doubtful accounts,” if the outcome looks bad. Booking the loss straight to 654 on notification distorts net income if the representment succeeds. Conversely, when disputes become a recurring pattern, the close calls for a provision for disputes (1511) or a write-down of receivables (491), on a documented statistical basis.

ℹ️

VAT on a lost dispute

Article 272 of the French tax code (CGI) lets a business recover the output VAT on a receivable that has become definitively uncollectible. A lost chargeback qualifies. In practice, you must prove the loss is final (network decision, all remedies exhausted) and keep the audit trail. For ordinary unpaid invoices, the rule is still to send a duplicate invoice carrying the required legal statement.

🎯 Quick question

A chargeback has just been notified, but you have strong evidence and plan to fight it. How do you record it?

Chapter 5. VAT on payment fees, and matching.

The first VAT principle to remember: payment services are exempt as a rule. Article 261 C of the French tax code (CGI), which transposes article 135 of the EU VAT Directive, exempts banking and financial transactions, including card processing fees. A Stripe or PayPal invoice therefore usually shows no VAT, and there is nothing to recover. The exemption is not universal, though. Banks can opt into VAT under article 260 B of the CGI, and technical services (terminal rental, gateway, fraud prevention, reporting) are taxable at 20%. Only the invoice settles the question.

Fee	VAT treatment	Expense account	VAT recoverable?
Card processing fee (acquiring bank)	Exempt as a rule (CGI art. 261 C), unless the bank opts in (art. 260 B)	627	Only if VAT appears on the statement/invoice
PSP processing fees (Stripe, PayPal...)	Exempt (financial service, art. 135 of the VAT Directive)	627	No, no VAT charged
Card terminal rental	Taxable at 20%	6135	Yes
Gateway, fraud prevention, reporting, technology services	Generally taxable at 20%	611 / 627 depending on the service	Yes, if shown on the invoice
Dispute fee (chargeback fee)	Follows the provider's treatment (usually exempt)	627	Per the invoice

VAT treatment of payment fees (France, mid-2026)

🔑

Never assume VAT

Recovering a “theoretical” 20% VAT on exempt bank fees is a classic trigger for a tax reassessment. The defense is a systematic habit: read the invoice or the statement. No VAT shown means no recovery. Conversely, leaving the VAT charged on terminal rental buried in 627 instead of posting it to 44566 means losing cash.

The chapter's second pillar is matching, which pairs debits and credits within the same third-party account (411 for customers, 467 for PSPs) to isolate what is still owed. Applied to payments, it feeds a three-way reconciliation. The sales journal shows what was sold. The PSP statement shows what the PSP collected, withheld, and paid out. The bank statement shows what actually arrived. Every discrepancy has a limited set of causes: fees, refunds, chargebacks, reserves, timing differences. Each cause has its own entry.

Reconcile sales ↔ PSP statement: every order in the journal must appear in the statement (amount, reference, date). Missing ones are failed payments or sales that were never captured.
Explain the gross → net bridge: for each payout, break out fees, refunds, disputes, and any holdbacks (rolling reserve), and post the matching entries.
Reconcile payouts ↔ bank: every announced payout must show up on the bank statement for the right amount. Match 467, then 512 through the bank reconciliation.
Handle what is left: anything that does not match goes for investigation, and to 471 only while it is being identified.

🎯 Quick question

Your monthly Stripe invoice shows no VAT on processing fees. Why?

Chapter 6. Monthly close and marketplaces: third-party funds.

The monthly close on payment collection is a proof routine. It shows that every euro of sales is either in the bank, in identified transit, or in a dispute being tracked. It relies on cut-off (assigning sales and flows to the right period), support for transit accounts, and coverage of known risks. Done rigorously every month, it makes the year-end close and the audit almost painless.

Cut-off for sales and flows: sales from the last few days of the month that settle the following month stay in 5115/467, not 512.
Bank reconciliation for every 512 account, with discrepancies documented.
Support for 471: every line identified, posted, or refunded; any residual balance explained in writing.
Matching of 411 and 467: anything unmatched after 30 days goes for investigation (follow-up, dispute, doubtful).
The month's PSP fees recorded from the statement or invoice, with VAT recovered only if it was charged.
Provisions: open disputes (1511) and write-downs of at-risk receivables (491), on a documented basis.
Check 580: the balance must be zero; otherwise an internal flow has gone missing.
Reconciliation of third-party funds (marketplaces): the safeguarded balance must equal the total owed to sellers.

Marketplaces add a regulatory dimension: collecting buyers' money to pass it on to third-party sellers means providing a payment service under PSD2. Without a payment institution license, agent status under a licensed provider, or an applicable exemption, the activity is illegal. The standard solution brings in a licensed partner (a payment institution or e-money institution) that collects the funds and safeguards them in a dedicated account. The platform never touches third-party money.

Marketplace flow with safeguarding

Buyer

pays €100 on the marketplace

The funds are collected by the licensed partner institution, never by the platform itself

Partner PI / EMI

safeguards the funds

Safeguarding account kept separate from the provider's own cash: the €100 is protected, even if the provider goes bankrupt

Marketplace

invoices its €15 commission

Only the commission is revenue: credit 706 + output VAT, as a receivable from the seller or withheld from the payout

Third-party seller

receives €85

The licensed institution makes the payout; the platform books no revenue and no expense on these €85

Payment providers for platforms and marketplacesStripeAdyen

MangopayLELemon WayPayPal

⚠️

GMV is not revenue

The gross merchandise volume (GMV) flowing through the marketplace is never revenue. Booking the €100 in 707 and then the €85 as an expense artificially inflates revenue, with tax, payroll-tax, and financial-reporting consequences. The platform's revenue is limited to its commission (706) and any service fees. At the close, the amount owed to sellers (467) must reconcile to the cent with the safeguarded balance at the partner.

🎯 Quick question

A marketplace collects €100 for a third-party seller through its safeguarding payment institution and keeps a €15 commission. What is the marketplace's revenue?

Accounting for payments: from card receipt to balance sheet. 6 chapters and a final quiz.

Chapter 1. How payments show up in the books.