Cash Position Reports for Corporate Treasury Teams

Summary

A corporate client wants a cash position by entity and currency, not a folder of single-account statements. A document built as account sections under one consolidated page, with stated balance definitions and rate dates, answers that question. End-of-day, intraday and month-end documents need different generation patterns, and the scope each reader sees is fixed when the document is generated. For CTOs and transaction banking leaders at banks serving corporate clients.

At 8:40 on Monday morning a treasury analyst at a manufacturing group opens a folder containing twenty-three PDFs from her bank, one for each account. The group has four legal entities and five currencies. Each PDF is laid out like a retail statement: opening balance, a list of transactions, closing balance. What she needs is a single answer. How much cash does the group hold, by entity and by currency, as of Friday's close? She copies the closing balances into a spreadsheet, looks up the rates, converts, and checks the total against the figure in her finance system. It takes forty minutes, and on a bad Monday one account is missing from the folder.

From the bank's side this is a document problem more than a data problem. The balances she needs all sit in the bank's core systems. What is missing is a document shaped like the question the client is asking. This post covers how the roll-up is structured, which generation patterns the different cadences need, how per-client layouts are handled without a template for each client, and where the scope of each reader's view is decided.

How a Corporate Statement Differs From a Retail One

The two documents are read by different people for different reasons.

Dimension	Retail statement	Corporate statement
Reader	The account holder	A treasury team, often with a finance system downstream
Accounts in one document	One, or a few	Dozens, under several legal entities
Currencies	One or two	Several, with a reporting currency for totals
Question answered	What happened on my account	What cash do we hold, where, and in what currency
Cadence	Monthly	End of day, intraday on request, and month-end
Layout	The same for all customers	Agreed per client in the relationship

The difference is more than size. A retail statement is a record of one account's activity. A cash position report is a view across accounts, and for many readers the balances matter more than the transactions, because the balances are what the client reconciles against its own books. Transaction detail still has a place, behind the position.

The Roll-Up: Entity, Account, Currency

A position report works in two layers. The first shows each account in its own currency, as the bank's records hold it. The second shows the roll-up in a reporting currency the client has chosen, so that entities and currencies can be added together. A figure converted at the account level hides what the account holds, and a roll-up of native amounts alone cannot be summed.

Consider a group with three entities and six accounts at the bank. The reporting currency is EUR. The rates below are invented for the example.

Entity	Account	Currency	Closing balance (native)	Rate to EUR	Equivalent in EUR
Harlow Industrial Ltd	Operating	GBP	1,250,400.00	1.1500	1,437,960.00
Harlow Industrial Ltd	Operating	EUR	310,250.75	1.0000	310,250.75
Harlow GmbH	Operating	EUR	2,104,880.20	1.0000	2,104,880.20
Harlow GmbH	Payroll	EUR	(68,420.10)	1.0000	(68,420.10)
Harlow Inc	Collections	USD	1,875,300.50	0.9300	1,744,029.47
Harlow Inc	Disbursements	USD	240,115.35	0.9300	223,307.28
Total					5,752,007.60

The same six rows answer both of the treasurer's questions. By entity, in EUR, the position is 1,748,210.75 for the UK company, 2,036,460.10 for the German company and 1,967,336.75 for the US company. By currency, the group holds GBP 1,250,400.00, EUR 2,346,710.85 and USD 2,115,415.85. Each view adds up to the same 5,752,007.60.

One cent in this example is worth a closer look. Converting the USD total of 2,115,415.85 at 0.9300 gives 1,967,336.74, while adding the two rounded account equivalents gives 1,967,336.75. Neither figure is wrong. The page needs a stated rule, and the rule belongs to the bank and the client agreement. Here each account's equivalent is rounded first and totals add the rounded figures, so that each column foots. The report prints the rule next to the rates, so an analyst who finds a cent of difference on her own spreadsheet can see why.

Three other items belong on the page itself and not in a footnote:

The balance definition. A ledger balance, an available balance and a projected balance that includes value-dated items are different numbers. The client agreement fixes which one a cash position uses, and the column heading says which it is.
The rate source and rate date. A total converted at a stale rate is accurate arithmetic on the wrong input.
The as-of time. An end-of-day position gives the business date it closes. An intraday position gives a time of day.

The same structure, with several entities and currencies behind one document, appears in consolidated reporting for family offices. The corporate version differs in its cadence, and in that the bank owns the balances.

Three Triggers, Three Generation Patterns

A single client may receive three kinds of position document, and they do not behave alike.

Pattern	Trigger	Data as of	How to treat the document
End of day	Completion of the bank's end-of-day processing	Close of the business day	The daily position
Intraday	The client asks, from the channel it uses	A stated time today	Indicative, because balances can still change
Month-end	The calendar, after the month-end close	Month-end	The formal statement, with transactions

End of day. The natural trigger is the completion of end-of-day processing and not a clock time. A report scheduled for 06:00 will, on the morning a batch runs late, quietly show the previous day's balances under today's date. If the end-of-day process starts the report itself, the label cannot disagree with the numbers.

Intraday. A person requests an intraday position, often from the channel they already use, and expects it quickly. The document should say "as of 11:42" prominently, and say that it is indicative. It is a snapshot for decisions and not a record, and a client who confuses the two may quote an intraday figure back to the bank.

Month-end. This is the formal statement: balances, full transaction detail, and whatever the client agreement requires. A client with dozens of accounts and thousands of transactions produces a long document, so test the longest realistic client for clean pagination, not the average one.

Layouts Agreed in the Client Agreement

Corporate clients negotiate how their documents look. The terms are often modest, but they differ from client to client: the reporting currency, whether the position is grouped by entity first or by currency first, the language, which accounts are included, whether the document carries transaction detail or balances alone, and who receives it through which channel.

The tempting way to honour these terms is to copy the template for each client and edit the copy. With forty clients that is forty templates, and a change to the rate footer becomes forty changes. The alternative is a client profile held in the bank's own system, with each negotiated term as a field, and a small number of layout variants maintained once. The profile is passed in when the document is generated, and branding is handled through a theme and not through a copy.

Language is the one term that carries its own design questions; see multilingual reports from one template. A term that is not in the profile is a term the document cannot honour, so a new request becomes a decision about a new field and does not turn into a one-off copy.

Access: Scope Is Decided Before the Document Exists

Within a corporate client, people are entitled to different accounts: the UK company's finance manager sees the UK accounts, and the group treasurer sees all of them. A PDF cannot hide rows from the person who holds it, so scope is decided when the document is generated and not when it is read. Three consequences follow.

Generate for the scope. A group version and an entity version are two documents, each built from the list of accounts the recipient is entitled to see. The entitlement lives in the bank's channel or entitlement system, and the document receives the resulting list.
Totals follow the scope. An entity version whose total includes the other entities' accounts leaks them through arithmetic. Each subtotal and total should be computed from the rows the recipient may see.
Sent documents do not change. If an entitlement changes on Tuesday, the next document reflects it. The document sent on Monday does not, so the bank needs its own record of what it sent and to whom.

Separating one client's reporting environment from another's is a different question, covered in multi-tenant reporting security. Scope within a client is a generation question, and it is easier to get right when each document is produced for one scope, on purpose.

How This Maps to CxReports

Here is how that design maps to CxReports, using what the documentation states.

Account sections as subreports. A subreport is an independent unit with its own parameters, data sources and dictionaries. The documentation gives the example of repeating a subreport for each entry a query returns, and an account fits the same pattern. The parent report repeats an account subreport once for each account in the client's list and maps the account identifier into it, with accounts ordered by entity in the supplied data. A client with sixty accounts does not need a different template from a client with six.

The position page. The consolidated page is a Data Table bound to a roll-up data source with one row per account: entity, account, currency, native balance, rate and equivalent in the reporting currency. The table groups by entity and uses a footer aggregate, such as Sum, for the entity subtotals and the grand total. A second table on the page can use the table's Transform data option to group the same rows by currency, so the by-entity and by-currency views come from one data source and cannot drift apart. Empty text can be set for a client with no accounts in scope.

Formats. Native balances use currency formats such as currency;GBP;2;2;a for pounds with negative amounts in parentheses, rates use a number format such as n;4, and the as-of line uses a text template such as:

Cash position as of { $data.position.asOf :dt }

A column that carries several currencies can use the Expression format type, which resolves the format at generation time, or the table can be grouped by currency so each block has one format. Check in a preview that each row prints its own currency.

End of day, intraday and month-end. The three patterns map to three routes.

End of day. A Report Generation Job with a repeating data source of clients produces one document per client. It can run on a daily schedule, or the bank's end-of-day process can start it through the API's start-a-run call, passing the business date as a parameter, and then poll the run status. The second route ties the report to the completion of processing and not to a clock time.
Intraday. The API export call accepts params for report parameters and an inline data payload, together with lang, theme and template, and returns the PDF. The client's channel calls it when a treasurer asks, and passes the as-of time in the payload. The export endpoints return the file and do not send email, so the calling channel presents it.
Month-end. A Job on a monthly schedule can deliver by email, to Google Drive or to SharePoint, with one entry per client. It can also hold deliveries for review, so a person approves or rejects each document before it leaves, which suits a formal statement.

Per-client layouts. The profile fields arrive as report parameters. A Page Visibility Expression, which works from parameters, switches page sets, for example the transaction pages appear when the detail level is "full". Fixed labels in each language live in a dictionary, and a theme carries a client's styling. The documentation does not describe how hidden pages affect page numbering or a table of contents, so test those with each page set before relying on them.

Scope. The entitled account list arrives in params or data, and the data source applies it as a filter. Because group and grand totals aggregate the rows the table receives, a document generated for a narrower scope totals the rows in that scope. Test this with a deliberately narrow scope and check that no subtotal includes an excluded account. The export call also accepts a password option to protect the PDF, which is relevant where a document leaves the bank's channel by email.

Several things stay with the bank by design. The rates, the converted equivalents and the rounding rule arrive as data, and CxReports formats and positions them without deciding them. The balance definition, the entitlements and the client agreements are likewise the bank's decisions. Electronic statement formats that a treasury system may ingest, such as SWIFT MT940 or ISO 20022 camt.053, come from the bank's payments and core systems. The documented outputs here are PDF and, through an optional licensed module, Word, Excel and PowerPoint. The documentation describes Job run history, but long-term records of what each client received stay in the bank's own systems.

Getting Started

Corporate statement need	CxReports mechanism	What stays with the bank
One layout for any number of accounts	Account subreport repeated per account	The account list per client
Position by entity and by currency	Data Table with grouping, footer aggregates and Transform data	The roll-up rows, rates and rounding rule
Native currency display	Currency formats, Expression format type or grouping by currency	Native balances and balance definition
As-of date and time on the page	Text template with the `dt` format	The timestamp supplied with the data
End-of-day run tied to processing	Job started through the API, with the business date as a parameter	The end-of-day process that triggers it
Intraday on request	API export with `params` and inline `data`	The channel that calls it
Month-end formal statement	Scheduled Job with hold-for-review and delivery	Review sign-off and the client agreement
Per-client layout	Parameters, Page Visibility Expression, themes, dictionaries	The client profile
Scoped documents	Entitled account list as a filter	Entitlement data

Documentation:

To see a cash position report built from your own accounts, entities and currencies, request a demo.

This article covers reporting and document design. The names, balances and rates are illustrative. Balance definitions, rate and rounding disclosures, and the content of statements for corporate clients depend on your jurisdiction, your client agreements and your regulators, and are determined by your compliance and product teams. Nothing here constitutes financial, legal or regulatory advice.