A Cobase cash-pooling position needs a separate intercompany loan record
Cobase documents a platform connecting banks and accounts with payment, cash-management, forecasting, in-house-banking, and cash-pooling modules. A pooled position can support liquidity operations, but it does not by itself document which entity borrowed or lent, under what authority, on which terms, or how the movement was booked.
Editorial figure by Treasury Operations Review. Source context: Cobase official product or service record.
Name the legal entities behind every pooled balance
Cobase's official page places cash pooling alongside bank connectivity, payments, forecasting, and in-house banking. The direct answer is that a consolidated liquidity view can show how cash is arranged without establishing the legal and accounting relationship created by each movement. The bank account holder, pool leader, participant, guarantor, currency owner, beneficial owner, and reporting entity may differ, especially across borders and multi-tier structures.
The pool design record should identify every legal entity and account, bank, country, currency, structure, ownership, participation status, permitted direction, target or threshold, concentration frequency, limits, and effective dates. Each movement should retain the originating and receiving entities, accounts, value date, amount, currency, instruction, bank reference, and structure rule. Do not infer an intercompany lender or borrower from a dashboard hierarchy that was designed for operational visibility.
Keep authority and terms outside the position calculation
A technically valid sweep can still exceed corporate authority, agreement limits, local restrictions, covenant terms, minority protections, or approved liquidity policy. Treasury, tax, legal, accounting, and local finance owners may each control a different part of the decision. The retained governance record should name the participation agreement, board or delegated authority, borrowing and lending limits, currencies, maturity logic, pricing method, interest basis, withholding or other tax review, guarantees, termination rights, and exception approvals.
System rules should reference those approved terms and expose mismatches before release. Test new entities, account changes, negative balances, limit breaches, unavailable statements, holidays, daylight overdrafts, cross-currency movements, sanctions or fraud holds, and emergency funding. A manual override should state who authorized it, the reason, duration, affected movements, compensating review, and how it will be reconciled rather than simply bypassing the configured threshold.
Reconcile bank movement, intercompany loan, and ledger
The operational chain should connect the approved pool rule, forecast or balance input, proposed concentration, payment authorization, transmitted instruction, bank acknowledgement, account statement, settled value, intercompany loan or deposit record, interest accrual, tax entries where applicable, and general-ledger posting. These are related but separate events. An accepted instruction is not settlement, a bank movement is not a complete intercompany agreement, and a dashboard balance is not a reconciled ledger.
Daily and period-end controls should compare pool-system positions, bank statements, in-house-bank subledgers, intercompany balances, interest calculations, foreign-exchange effects, and entity ledgers. Investigate timing differences, rejected or returned sweeps, duplicate transfers, back-valued items, account closures, changed rates, unmatched counterparties, and reopened periods. Preserve original and corrected records so eliminations and disclosures can be explained without reconstructing history from net totals.
Keep Cobase claims inside the official record
The registered Cobase page establishes current provider positioning for multi-bank and multi-account access, payments, cash management, ERP connectivity, reporting, authorizations, forecasting, in-house banking, and cash pooling. It does not establish legal capacity, enforceability of an intercompany agreement, authorized borrowing or lending, tax or transfer-pricing treatment, accounting classification, accurate balances, or final bank settlement in a particular deployment.
Treasury Operations Review reviewed the registered source on August 18, 2026 and did not operate a customer environment. Buyers should verify current entity and account models, pooling structures, bank coverage, value dating, authorization workflows, limits, agreement references, interest and fee calculations, statements, accounting entries, reconciliation, exceptions, audit exports, integrations, security, and service dependencies with representative entities and transactions.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Treasury Operations Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.