How TMS + VAM Redefine Payment Account Architecture for Deep Cash Management

01 What Does a Traditional Fund System Look Like?

Enterprises typically evolve from simple bank‑account monitoring to cash‑flow planning, financing, and risk management. Each stage shows a different picture, but three recurring problems appear:

Balance is visible but not understood – knowing an account holds ¥100 million does not reveal how much is free, reserved for suppliers, or held in regulatory accounts.

Transactions are hard to attribute – a single bank receipt may correspond to dozens of orders, and the mapping between account‑level statements and business‑level entities (customers, stores, projects) is missing.

Only post‑event reconciliation is possible – cash‑shortage, payment delays, or FX loss are discovered after they occur, because forecasts lack business‑driven data.

The root cause is that business data and account data are not connected.

02 How to Link Transactions to Funds?

Enter the dual‑engine model: Treasury Management System (TMS) for group‑level financial control and Virtual Account Management (VAM) for transaction‑level business fund handling.

2.1 TMS – The Group‑Level “Brain”

TMS aggregates balances across subsidiaries, banks, and currencies, answers questions such as which accounts are over‑balanced, which entities may run out of cash, and when loans mature. It provides a unified view for liquidity, financing, investment, and risk decisions. However, when TMS only receives bank and accounting data, it cannot explain the business origin of each cash movement, limiting cash‑flow forecasts.

Example: a ¥10 billion‑revenue manufacturer spends three days each week on cash‑week reports; a sudden fund‑transfer request fails because ¥8 million of the apparent balance is locked as guarantee deposits, which TMS cannot identify without business‑level data.

2.2 VAM – The Transaction‑Level “Nervous System”

VAM runs alongside business processes, using virtual accounts, rules, and internal ledgers to automatically recognize receipts, split payments, allocate funds to customers, stores, channels, or projects, and produce a business‑dimension cash ledger.

After a customer pays, the system matches virtual account, payer, memo, amount, and settlement rules to identify the exact business owner.

Platform‑level settlements are split to individual stores or merchants.

Enterprise‑initiated payments can be broken down to contracts, invoices, and business objects.

VAM answers concrete questions such as who paid, which orders are involved, whether refunds or fees exist, and whether the business is complete while the cash is settled.

2.3 Relationship Between TMS and VAM

TMS is the “brain” that decides how much liquidity is needed and how to allocate it; VAM is the “nervous system” that perceives business transactions, cleans up receipt‑recognition, split‑accounting, and reconciliation, and feeds enriched cash data back to TMS.

03 How TMS + VAM Work Together

The combined workflow forms a continuous data loop:

VAM processes business‑level receipts, payments, splits, and reconciliations, producing a cash record with full business context.

The enriched record is synchronized to TMS.

TMS incorporates the data into liquidity forecasts, financing decisions, FX risk, and policy constraints, then generates fund‑allocation instructions.

Instructions are executed via payment platforms, bank‑direct channels, or internal transfers; execution results are fed back to both TMS and VAM, updating the cash status for the next prediction cycle.

3.1 Detailed Example – Platform Settlement Flow

A nationwide retailer receives a consumer payment, the platform holds the money, deducts commissions, marketing fees, and refunds, then settles the net amount to the headquarters. In a traditional setup, finance would manually match platform statements to orders and bank statements, taking days.

With TMS + VAM, the flow is:

Consumer payment triggers order data sync to VAM.

Platform settlement enters the bank account; the bank returns the transaction record.

VAM automatically recognizes the payment, splits the total into individual orders, stores, and fees.

Refunds, commissions, and fees are reconciled simultaneously.

Resulting business‑dimension cash data is sent to TMS, updating available balance and cash‑flow forecasts.

TMS may then schedule collection, allocate funds, or trigger short‑term financing based on the updated forecast.

Execution results (e.g., actual disbursement) are returned to both systems, closing the loop.

3.2 Five‑Layer Architecture

The end‑to‑end cash‑management stack consists of:

Business & Transaction Layer – orders, contracts, procurement, payroll, channel data that define why and when money moves.

VAM Business‑Fund Layer – virtual accounts, receipt recognition, split‑accounting, internal ledgers that bind cash to business entities.

Fund‑Data Base Layer – unified master data for legal entities, accounts, virtual accounts, fund purpose, status, currency, value date, and permissions.

TMS Treasury Layer – liquidity, cash‑flow forecasting, financing, investment, FX, risk, and bank‑relationship management.

External Financial Institutions – banks, payment providers, lenders, and FX markets that execute the final settlement.

Accurate mapping of entities (legal entities, accounts, customers, suppliers, currencies, orders, contracts, stores, projects, payment methods, settlement rules) across these layers is essential for a seamless data flow.

3.3 VAM Makes Business Funds Usable

Beyond assigning a virtual account, VAM builds a full business‑fund ledger that links each bank entry to customers, orders, stores, channels, and projects. For a consumer‑goods group with multiple sales channels, VAM records at least ten dimensions per cash item, including legal entity, bank account, virtual account, counterpart, order, channel, fund nature, usable status, value date, and obligations.

Example: a platform settlement entry is decomposed into sales revenue, marketing fees, and refunds, each tied back to the originating order and store, turning a plain bank line into actionable business‑fund data.

3.4 TMS Arranges Funds to Meet Business Needs

TMS follows four continuous steps:

See the Present – aggregate balances, subtract restricted, frozen, pledged, and minimum‑operating amounts to derive truly disposable liquidity, distinguishing collectable, investable, and locally‑usable funds.

Forecast the Future – combine high‑certainty items (receivables, sales) with high‑certainty items (approved payments, loan maturities) and scenario data (strategic investments, potential financing) to produce short‑, medium‑, and long‑term cash‑flow forecasts, preserving versioning and deviation records.

Allocate Resources – based on the forecast, generate fund‑allocation commands (inter‑company transfers, pool collection/disbursement, internal borrowing, loan drawdown/repayment, deposits, payment batching, FX hedging) while respecting regulatory, tax, limit, and approval rules.

Validate Results – measure prediction accuracy, liquidity concentration, collection rate, idle cash, financing cost, investment return, FX P&L, straight‑through‑processing rate, exception‑handling time, and bank fees; analyze trade‑offs (e.g., higher collection vs. liquidity pressure) to continuously improve the model.

04 Case Study – Tangible Benefits

A multi‑national consumer‑goods group receives mixed payments each morning (direct store sales, e‑commerce, distributors, corporate customers). Before VAM, reconciling the ¥2 billion daily inflow to business sources took two‑three days.

After deploying VAM:

Each payment source receives a distinct virtual fund identifier, linking bank flows to store daily statements, settlement sheets, distributor invoices, or receivable tickets.

The system automatically identifies fees, refunds, split‑accounting requirements, and flags abnormal transactions for manual review.

At 10 am, TMS ingests the enriched data, detects a 30% drop in settlement from a specific e‑commerce market, attributes it to a promotion‑driven refund surge, and forecasts a short‑term cash gap for that legal entity.

Because cross‑border pooling is slow, TMS proposes four actions: early collection from key customers, postponing non‑critical purchases, tapping a local short‑term credit line, and scheduling repayment after the next settlement.

Execution results are fed back, the cash gap shrinks, and the system records the deviation to improve future forecasts.

The outcome: finance staff spend five days less on manual reconciliation, decisions are data‑driven, and cash‑shortage risks are mitigated proactively.

Conclusion

Deep cash management transforms enterprises from merely viewing account balances to explaining why money arrived, predicting future cash movements, and orchestrating optimal fund usage. TMS provides the enterprise‑wide treasury view; VAM delivers transaction‑level business fund visibility. Their integration creates a closed‑loop where business events, cash receipt, reconciliation, forecasting, allocation, execution, and verification continuously reinforce each other, enabling mature, data‑driven financial operations.