This distinction matters for budgeting, refunds, employee access, expense tracking, and bookkeeping.<\/p>\n
A card transaction records value moving to or from the card account. A merchant balance records value held and used inside the supplier\u2019s system.<\/p>\n
They are connected, but they are not the same ledger<\/strong>.<\/p>\n A single top-up can fund many later purchases without creating another card charge each time.<\/p>\n In a direct-charge model, the merchant submits a card transaction for a specific order, invoice, booking, or subscription renewal.<\/p>\n The card transaction and commercial record can usually be connected through:<\/p>\n Authorisation and final capture may occur at different times, but the card payment still relates to a particular commercial event.<\/p>\n In a balance-based model, the customer first adds funds, purchases credits, redeems a voucher, or receives a refund into an internal wallet.<\/p>\n Later orders are deducted from that stored value.<\/p>\n The individual order may not create a new card transaction because the card was already charged when the merchant balance was funded.<\/p>\n Some platforms use a hybrid model. They may consume available credit first and charge the card only for the remaining amount.<\/p>\n Others keep different balance types, such as:<\/p>\n Do not assume that every figure labelled \u201cbalance\u201d represents the same type of value.<\/p>\n Understanding the payment flow becomes much easier when the records are separated into three layers.<\/p>\n The card ledger may show:<\/p>\n It tells you what happened to the card.<\/p>\n However, it may not explain which later purchase consumed money that had already been transferred into a merchant wallet.<\/p>\n The merchant ledger may show:<\/p>\n It explains how value moves inside the supplier\u2019s platform.<\/p>\n These include:<\/p>\n These records explain what the business actually purchased and how the expense should be recorded.<\/p>\n The three records should be reconciled together rather than forced into a one-to-one pattern.<\/p>\n For example:<\/p>\n One \u20ac500 card charge may fund ten later orders.<\/p>\n Or:One \u20ac120 order may use \u20ac100 of merchant balance and create only a \u20ac20 card charge.<\/p>\n Common signs include:<\/p>\n Be careful with terminology.<\/p>\n A platform may also use the phrase balance due<\/strong>, which means money the customer owes rather than money available to spend.<\/p>\n Check what the number actually represents.<\/p>\n When a business tops up a merchant account, it transfers value before all goods or services have necessarily been purchased.<\/p>\n That means:<\/p>\n Funding event \u2260 Purchase event<\/strong><\/p>\n For example, the card may be charged in March, while the merchant balance is gradually consumed between March and June.<\/p>\n If finance assigns the entire March top-up to one project, later project costs may be distorted.<\/p>\n Keep both:<\/p>\n The merchant may issue different document types, such as a funding receipt, payment confirmation, credit-purchase invoice, or individual order invoice.<\/p>\n Which documents are required for accounting depends on the merchant and applicable accounting rules.<\/p>\n Assume a design team adds \u20ac600<\/strong> to a platform using a dedicated virtual card.<\/p>\n The platform also provides \u20ac30 in promotional credit<\/strong>.<\/p>\n Three employees then purchase services costing:<\/p>\n Total purchases: \u20ac490<\/strong><\/p>\n Later, one \u20ac20 purchase is refunded to the platform balance.<\/p>\n The remaining \u20ac160 may contain both refundable funds and restricted promotional credit.<\/p>\n It should not automatically be treated as \u20ac160 of cash unless the merchant confirms the full balance is refundable or withdrawable.<\/p>\n A card refund<\/strong> returns value through the card-payment route and should eventually appear in the card ledger.<\/p>\n A merchant-balance refund<\/strong> restores value inside the merchant account.<\/p>\n That balance may only be usable with the same supplier.<\/p>\n Before cancelling a service or requesting a refund, confirm:<\/p>\n Do not mark an invoice as card-refunded just because the merchant dashboard shows an internal credit.<\/p>\n Until the card ledger displays the refund, the value remains on the merchant side.<\/p>\n Some platforms automatically charge the card when:<\/p>\n This can make a user think that the card was charged for a specific order when the real trigger was simply an auto-replenishment rule.<\/p>\n For each merchant account, record:<\/p>\n If an unexpected card charge appears, review the merchant ledger before assuming the transaction is incorrect.<\/p>\n A legitimate auto top-up may correspond to a low-balance event.<\/p>\n Card controls work best when they reflect how the merchant actually charges.<\/p>\n A card limited to exactly \u20ac120 may not work if the merchant requires a minimum \u20ac500 wallet top-up.<\/p>\n Likewise, a one-time card may not suit a merchant that uses:<\/p>\n Before setting limits, understand whether the merchant charges:<\/p>\n Then review card suitability, available balance, supported currency, merchant requirements, and any applicable limits.<\/p>\n A merchant balance is only practically controlled by the business if the business controls the merchant account.<\/p>\n A wallet created using an employee\u2019s personal email can become difficult to access after that employee leaves.<\/p>\n Business accounts should ideally use:<\/p>\n Also separate permissions.<\/p>\n A person who can place orders does not necessarily need authority to:<\/p>\n Removing a virtual card does not remove an employee\u2019s ability to spend money already stored inside the merchant account.<\/p>\n Stored merchant value may not always behave like cash.<\/p>\n Credits may be:<\/p>\n Before transferring a large amount to a merchant wallet, check what happens if:<\/p>\n A card limit can control how much money enters the merchant account.<\/p>\n It cannot automatically recover value that has already been transferred.<\/p>\n For material balances, avoid keeping significantly more value than the business realistically expects to use in the near term.<\/p>\n A card may fund a merchant account in one currency while services are priced in another.<\/p>\n Some platforms convert:<\/p>\n Record:<\/p>\n For refunds, confirm whether the merchant returns the original currency, converts the value into the wallet currency, or refunds the card directly.<\/p>\n Do not infer supplier location or tax treatment from the wallet currency alone.<\/p>\n A practical month-end process can be:<\/p>\n A useful formula is:<\/p>\n Opening Balance + Top-Ups + Credits \u2212 Purchases \u2212 Fees \u2212 Expirations \u2212 Withdrawals = Expected Closing Balance<\/strong><\/p>\n Keep restricted promotional credits separate if they cannot be treated like ordinary funds.<\/p>\n Avoid:<\/p>\n![\"\"](\"https:\/\/wordpress.buvei.com\/wp-content\/uploads\/2026\/09\/Merchant-Balance-vs-Direct-Card-Charge2-1024x575.png\")
<\/h2>\nTwo Payment Models<\/h2>\n
Direct Card Charge<\/h3>\n
\n
Merchant Account Balance<\/h3>\n
\n
Follow the Money Through Three Ledgers<\/h2>\n
Card Ledger<\/h3>\n
\n
Merchant Balance Ledger<\/h3>\n
\n
Commercial and Accounting Records<\/h3>\n
\n
![\"\"](\"https:\/\/wordpress.buvei.com\/wp-content\/uploads\/2026\/08\/BUVEI\u5e7f\u544a\u56fe.png\")
<\/a><\/h2>\nHow to Recognise an Internal Balance<\/h2>\n
\n
A Top-Up Is Not the Same as a Purchase<\/h2>\n
\n
A Worked Reconciliation Example<\/h2>\n
\n
\n\n
\n \nEvent<\/th>\n Card Ledger<\/th>\n Merchant Ledger<\/th>\n Business Record<\/th>\n<\/tr>\n<\/thead>\n \n Top-up<\/td>\n \u20ac600 charge<\/td>\n +\u20ac600<\/td>\n Funding receipt<\/td>\n<\/tr>\n \n Promotion<\/td>\n No card entry<\/td>\n +\u20ac30<\/td>\n Promotion terms<\/td>\n<\/tr>\n \n Three purchases<\/td>\n No new charge<\/td>\n \u2212\u20ac490<\/td>\n Order records \/ invoices<\/td>\n<\/tr>\n \n Refund<\/td>\n No card refund<\/td>\n +\u20ac20<\/td>\n Refund record \/ credit note<\/td>\n<\/tr>\n \n Closing position<\/td>\n \u20ac600 top-up remains posted<\/td>\n \u20ac160 remaining<\/td>\n Reconciliation record<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n ![\"\"](\"https:\/\/wordpress.buvei.com\/wp-content\/uploads\/2026\/09\/Merchant-Balance-vs-Direct-Card-Charge4-1024x575.png\")
<\/h2>\nRefund to Card vs Refund to Merchant Balance<\/h2>\n
\n
Automatic Top-Ups Can Hide the Real Payment Trigger<\/h2>\n
\n
\n
Virtual Card Controls Should Match the Merchant Model<\/h2>\n
\n
\n
![\"\"](\"https:\/\/wordpress.buvei.com\/wp-content\/uploads\/2026\/09\/Merchant-Balance-vs-Direct-Card-Charge1-1024x575.png\")
<\/h2>\nEmployee Access and Account Ownership<\/h2>\n
\n
\n
Expiry and Stranded Balance Risk<\/h2>\n
\n
\n
Currency Layers Inside a Merchant Wallet<\/h2>\n
\n
\n
Month-End Reconciliation<\/h2>\n
\n
Common Mistakes<\/h2>\n
\n
Where Buvei<\/a> Fits<\/h2>\n