Effective treasury management for platform finance teams starts with one dependable cash truth across TMS, ERP, bank, and payment-platform data. From there, add controlled cash pooling, forecast confidence bands with forecast-to-actual checkpoints, and investment guardrails that pause optional actions when reconciliation breaks or stale balances remain unresolved.
A Treasury Management System should act as an operating control layer, not just a reporting screen. If your setup does not hold up during reconciliation and payment execution, the feature list is secondary.
In practice, a TMS automates treasury work such as cash flow and banking relationship management. In modern treasury, that scope includes payment execution, not only post-fact reporting. For platform finance teams, that distinction matters because cash decisions are made while funds are moving. A dashboard can look healthy while the position is still wrong if banking activity or reporting inputs are incomplete.
This article takes an operating view of three areas that are often handled too loosely: cash pooling, cash flow forecasting, and investment management. The focus is practical: what to implement first, what to verify before you trust outputs, and which decisions depend on legal, tax, and operating context rather than internal preference.
Cash pooling shows why discipline matters. It consolidates balances from subsidiaries or business units into a centralized structure. The two principal forms are notional pooling, where balances stay in separate accounts and are offset for interest, and physical pooling, where funds are transferred into a central pool account. Physical pooling can centralize cash, but it can also add administration and counterparty-related risk.
The same caution applies to forecasting and investment decisions. A TMS can support cash flow, investments, liquidity, and risk management, but outputs are only as reliable as the operating evidence behind them. A practical starting checkpoint is to identify gaps in accuracy, reporting, and cash-flow monitoring before expanding treasury actions.
Treat pooling and internal funding design as cross-functional decisions, not treasury-only calls. Legal and tax review may be required, especially where intercompany interest treatment is relevant. Formal agreements among participating cash-pooling parties should be in place before rollout. Those documents are part of the control evidence that makes decisions auditable later.
At close, keep verification simple. Confirm that banking activity, treasury records, and expected cash movement all line up, especially for accounts and entities involved in pooling and related treasury actions. If a break cannot be explained quickly, defer optional treasury actions until the issue is classified.
That operating model runs through the rest of this piece. Because implementation requires significant investment, the priority is not full automation on day one. The priority is one dependable cash truth first, then controlled pooling, tighter forecasting, and investment controls your team can repeat, verify, and defend.
Related: Days Payable Outstanding (DPO): How Payment Platforms Help Finance Teams Optimize Cash Flow.
Your Treasury Management System should serve as a cash and liquidity control layer, not just a reporting surface. At minimum, it should give you a unified cash-position view that brings together bank activity, ERP data, and payment-platform data in a way your team can verify.
This is not just an efficiency issue. Disconnected systems, manual reporting, and incomplete feeds create decision risk. They can also lead to missed opportunities, unnecessary borrowing, and weaker decisions.
| Required capability | Primary owner | Evidence artifact | What to verify before you rely on it |
|---|---|---|---|
| Bank account visibility | Treasury operations | Current account inventory and feed status | Active operating and settlement accounts are reflected in the cash-position view, and ownership aligns with actual usage |
| ERP connectivity | Finance systems or controllership | Interface mapping and reconciliation checks between ERP cash accounts and TMS balances | Core entities and currencies are covered, and breaks are investigated |
| Payment-platform connectivity | Treasury operations with finance systems | Mapping of payment-platform data into TMS cash positions | Payment data is flowing into the same cash-position view as banks and ERP |
| Forecasting | Treasury or finance planning | Forecast model with assumptions and confidence bands | Inputs include connected bank, ERP, and payment-platform data, and best-case, worst-case, and expected ranges are reviewed |
| Governance and data quality controls | Treasury lead with controller support | Governance register and exception log for integration and data issues | Owners are named, exceptions are visible, and remediation actions are tracked |
Set a clear acceptance rule: if ERP, bank, or payment-platform connectivity is partial, treat forecast output as advisory. Use it for direction until integration and data-quality gaps are resolved.
Add forecast confidence bands early, even with a basic model. Best-case, worst-case, and expected ranges make uncertainty explicit. They also help you spot data quality gaps before they turn into execution mistakes.
Before launch, define governance and exception-handling requirements that fit your environment. If your team cannot trace key decisions and exceptions across systems, treasury control is not production-ready.
If you are making funding, sweep, or investment decisions, tie them to one report-date cash position and reconcile everything else back to it. One workable approach is to use the TMS as the daily operating view, then tie it to ERP postings and bank records.
This comes down to cutoff clarity. A cash position is decision-ready only when the as-of date is explicit, included sources are clear, and open items are visible. Without that, a polished view can still create liquidity gridlock.
Assign each system a clear job before you trust the balance:
When they disagree, treat the difference as a break to classify, not a number to smooth over. Keep enough movement-level detail to trace what changed, where it came from, and whether it belongs in available cash.
Use a compact daily control pack so treasury, controllership, and finance operations can review cash position, in-flight activity, and reconciliation breaks quickly. The exact pack format can vary.
| Example view | What it should show | Decision check before action |
|---|---|---|
| Opening and closing cash | Start and end position by entity, currency, and account set | As-of date is explicit and prior close ties forward |
| In-flight items | Movements not yet fully reflected across systems | Open items are visible and not double-counted |
| Unreconciled breaks | Mismatches, ownership, and aging | Breaks are classified and tracked to resolution |
Keep the pack with supporting tie-out and exception records. The point is internal control, not presentation. Show what was checked, what remained open at cut, and what changed afterward.
Timing differences across feeds and postings can make cash look complete when it is not. Label source freshness clearly in the pack and separate report-date position from later updates. If late changes arrive, append a subsequent-events note rather than rewriting the original view.
That habit keeps close decisions defensible and makes reviews faster when teams need to explain why cash looked different at different points in the day.
For a step-by-step walkthrough, see How to Build a Finance Tech Stack for a Payment Platform: Accounts Payable, Billing, Treasury, and Reporting.
Choose the pooling model your entity structure, bank setup, and control maturity can support in production, not the one that looks most efficient on paper.
Cash pooling can reduce idle balances, ease borrowing pressure, and improve allocation efficiency when cash is spread across entities and accounts. But tighter central control can raise governance overhead, especially when entities span regions, bank capabilities are uneven, or treasury and accounting still depend on manual handoffs.
If entities span multiple regions and bank capabilities are uneven, many teams start with constrained pooling and explicit transfer approvals before broader automation. Use that phase to prove visibility, approvals, and intercompany handling.
| Pooling approach | Legal entity complexity | Bank support needed | Compliance review effort | Operational burden for in-house banking |
|---|---|---|---|---|
| Constrained concentration with explicit approvals | Can be used while entities, currencies, or regions are still being standardized | Depends on connectivity and bank coverage in your footprint | Review is still needed before rollout | Requires clear approvals, transfer tracking, and explanation of movements |
| Physical pooling | Depends on your entity and account structure | Requires reliable bank connectivity and execution support | Review should be completed before rollout | Requires ongoing governance, exception handling, and audit evidence |
| Notional pooling | Depends on grouping and bank program setup | Feasibility is heavily tied to bank program design | Review should be completed before rollout | Transfer mechanics differ, but governance, monitoring, and evidence work remain |
Physical and notional pooling are both established approaches for group liquidity management. In practice, the decision turns on entity complexity, bank visibility across entities, currencies, and geographies, and whether your team can run the controls after go-live.
Do not switch pooling on until three basics are in place:
| Precondition | What must be in place | Why it matters |
|---|---|---|
| Harmonized bank account management | An account inventory with ownership, currencies, and connectivity status across banks and jurisdictions | Direct bank connectivity with entity-, currency-, and geography-level visibility is the key checkpoint |
| Documented intercompany mechanics | Treasury and accounting aligned on how internal funding movements are approved and recorded | Preserve approvals, transfer details, and audit-trail support for treasury actions |
| Visibility in both TMS and ERP | The TMS shows the movement and resulting position, and ERP reflects the accounting impact without manual reconstruction | Pooling logic can outrun visibility and create late surprises in reconciliation or close if this is missing |
The key checkpoint is direct bank connectivity with entity-, currency-, and geography-level visibility. If that is missing, pooling logic can outrun visibility and create late surprises in reconciliation or close. As a second checkpoint on evidence quality, preserve approvals, transfer details, and audit-trail support for treasury actions.
Centralized cash control can improve liquidity use, but it also concentrates failure. A failure in bank connectivity or data flow can affect funding decisions across multiple entities.
Manual or disconnected cash management is already slow, error-prone, and reactive in complex environments, and pooling can amplify that weakness. If exception handling is weak or approvals are unclear, an efficient design can become fragile in production. If you are building in-house banking around the pool, operational burden can rise as entities and bank relationships increase.
Pooling feasibility and controls vary by market, bank program, and account setup, so treasury and legal confirmation should happen before rollout. Run scenario tests before full activation so you can see how long funding will last when conditions change. The goal is to confirm funding durability under change and verify that exception handling keeps the cash position decision-ready.
Use a simple sequence. Start with constrained approvals, prove clean bank account management and stable TMS-ERP alignment, then expand as visibility and exception handling stabilize.
For multi-entity and cross-border cash structures, see Global Treasury Management for Platforms: How to Centralize Cash Visibility Across 50+ Countries.
Forecasting should drive funding decisions in the current cycle, not just explain variance after close. Keep separate horizons, but reconcile both to one shared cash flow forecasting base. Use a short-horizon execution view for near-term liquidity moves and a longer-horizon planning view for runway decisions. These views can run at different cadences, including daily, weekly, and monthly, but they should pull from the same underlying cash position.
Build one shared cash base, then run two views from it. The execution view should focus on near-term movements and decision timing. The planning view should look ahead at runway. Both should tie back to the same balances and expected movements.
This only works when connectivity is reliable. Treasury tooling can consolidate bank accounts, subsidiaries, and currencies into one cash-position view. But fragile multi-bank or multi-ERP setups can break quickly, so treat integration weakness as a forecast-risk signal.
Document the inputs your team must refresh before acting on a forecast. Inputs vary by setup, but they should cover known maturities, interest, and principal settlements, plus other material expected cash movements.
Keep this as an explicit operating checklist for your setup, not a universal template. If key inputs are stale or missing, lower forecast confidence before moving cash.
Make forecast-to-actual reconciliation a checkpoint each cycle. Compare expected and realized positions, capture the drivers of variance, and document corrective actions.
Use explicit internal decision criteria for funding actions and keep evidence for each cycle: forecast snapshot, actual position, variance notes, and the decision taken. Scenario analysis is useful here because it shows how long funding lasts under changing conditions.
A treasury study found only 2% of C-suite respondents reported complete confidence in cash visibility. Treat that as a control reminder: a forecast earns trust when it reconciles to actuals and improves real funding decisions.
If your cash forecast depends on recurring revenue inputs, see Subscription Revenue Forecasting for Platform Teams Modeling MRR Churn and Expansion.
Do not allocate idle cash unless your forecast is reliable and the cash position reconciles cleanly. Treat control and auditability as non-negotiable. If forecast confidence drops or reconciliation breaks remain unresolved, pause discretionary investing until ownership and causes are clear.
Your policy should be operational, not aspirational. Define what decisions can be prepared in-system, who must approve, and what evidence must exist so each decision can be explained and audited later.
If your TMS supports investments, use it to automate preparation and tracking, not human judgment. The control model is deterministic execution. The system operates within policy, while named people retain policy, approval, and judgment responsibilities.
Auditability is a hard gate. If you cannot explain why a decision was made, under which rule, and by whom, do not run it as autonomous cash management.
Repeatedly clean recommendations can weaken review quality. A common failure mode is that after repeated flawless suggestions, approvals become rubber stamps while liability remains with the human approver.
Before moving cash, align the workflow around one explainable event trail for reporting and review. If evidence diverges across steps, control risk rises even when execution appears smooth.
Use a consistent cycle pack that ties the decision to evidence: forecast snapshot, current cash position, approval record, execution record, and the audit trail needed to explain ownership and decision logic.
Keep the checklist short, but enforce it as a stop-go control:
Technology can automate investments, liquidity, cash flow, and risk-management activity, but weak process design scales control failures faster. A practical rule is simple: cash you cannot explain is cash you should not allocate.
Treat FX and interest-rate exposure as an execution control once payout volume and currency mix start driving daily operations. If currency mismatch is recurring and material under your policy, move it from one-off conversions into approved hedging treatment with clearer pre-funding rules.
Start with a structural-versus-temporary split, then assign owner, review cadence, and approved response by class. Structural exposure comes from how the business runs across currencies. Temporary exposure is usually timing-driven, such as settlement lags or short-lived funding gaps.
Keep the register practical and decision-ready: entity, currency, exposure source, class, approved action, owner, and next review date. If ownership and review date are missing, treat the exposure as not yet controlled.
Use an if-then policy, not ad hoc judgment. If a mismatch repeats and starts affecting funding decisions, payout timing, or reported results under internal tolerance, escalate it into policy-driven management.
In practice, that usually means:
This is as much a control and scalability issue as a market issue. In one documented case, manual FX exposure modeling led to inconsistent hedge ratios and a process too fragile to scale. That same case described a move from fragmented macro-hedging to a structured back-to-back approach.
A centralized model can also improve control when exposures sit across affiliates by aggregating exposures for group hedging. In that documented model, affiliate-level risk was neutralized through central aggregation.
Your TMS should be the auditable trail, not a partial log. These platforms can combine cash and liquidity management, risk management, and payment processing, including international and multi-currency activity.
For each FX action or hedge, make sure one chain can be traced in-system:
For interest-rate-sensitive positions, keep the same discipline. Track maturities, interest, principal settlements, and related accounting workflows in the same record trail. If someone outside treasury cannot trace the decision and posting support without rebuilding it from email and spreadsheets, fix that before volume grows.
Related reading: Real-Time Reporting Metrics Platform Finance Teams Can Actually Control.
Standardize exceptions so they become treasury and control decisions, not endless queue work. Timely and accurate payments are a core control objective, so delays and errors should be handled as control exceptions, not only service tickets. For payout-heavy teams, one shared taxonomy across payment operations, the ledger, and treasury systems is more useful than ad hoc reason notes.
Build the taxonomy to do what formal financial classification codes are meant to do: classify, control, and account for activity. Every exception should carry the same core dimensions regardless of where it is detected: event type, probable cause, financial effect, current status, and owner.
As an internal operating model, use base event types that change cash certainty or close effort, such as payment failures, payment delays, reconciliation mismatches, and duplicate-processing risk. Then code to the lowest practical level so records are auditable and decision-ready, for example entity, currency, route, and cash state. If a code only says "payment issue," it is too vague for control and accounting.
A simple check is this: if a reviewer cannot tell whether cash moved, whether a customer was affected, and whether the ledger needs correction, the taxonomy is incomplete.
Document a fixed handling sequence in your internal playbook so teams stop solving the wrong problem first. One practical internal sequence is:
| Step | Action |
|---|---|
| 1 | Detect the event from bank, provider, or reconciliation signals |
| 2 | Classify it with the shared exception code |
| 3 | Assess customer and counterparty impact |
| 4 | Take the treasury action needed for funding or liquidity |
| 5 | Correct the ledger when the financial record is wrong or incomplete |
| 6 | Update the control to reduce recurrence |
Keep a complete evidence pack in each record: internal payment ID, external reference, entity, currency, amount, timestamps, customer impact, treasury decision, ledger action, and approver. A reviewer should be able to reconstruct the incident without reopening chats or email.
Exceptions should update your cash and liquidity management view promptly, not after cleanup. Payment operations and accounting and reporting need to stay connected, especially at close.
Use a strict close checkpoint: unresolved exceptions should appear in both the cash position view and the reconciliation pack until resolved. If a break carries into the next close cycle, keep its cash effect explicitly classified instead of leaving it in a generic suspense bucket.
When the same break repeats, escalate from casework to routing and control decisions. Recurring exceptions should change approval paths, funding assumptions, or routing choices until the pattern is addressed.
Use a qualitative escalation trigger. When recurrence starts to distort forecast confidence, close effort, or customer communication, escalate to treasury and finance leadership. At that point, the issue is a control-design problem, not a one-off payment incident.
Close and audit readiness come down to proof. A reviewer should be able to trace what happened, who approved it, what system executed it, and how balances or obligations changed. They should not have to reconstruct the story from chats or email.
Use explicit, reviewable artifacts instead of a generic "close complete" status. A practical pack names the evidence you rely on for approvals, execution, verification, and unresolved exceptions, with direct access to each item. A compact close pack can include:
If a reviewer cannot open and follow each record, the checkpoint is weak.
Keep one minimum evidence standard across treasury actions: who approved it, what executed it, and how it was verified. The key control is the recorded chain of observe, reason, act, verify, and log, because complete records can serve as the audit artifact.
This is where close pressure usually exposes gaps: approval in one tool, execution in another, and verification in a separate sheet. Fragmented systems and handoffs make traceability brittle, even when policy text looks complete.
Keep a short period summary of what failed, not only what your controls were supposed to do. Note recurring exception themes, affected entities or routes, actions taken, and what carried into the next close cycle, including red flags.
That summary helps finance and audit evaluate treasury decisions against operating risk in the period, not against planned controls alone. It also makes implementation gaps visible when "automation" still depends on manual evidence assembly.
If you are turning your close checklist into system controls, use the Gruv docs to map audit trails, payout states, and reconciliation surfaces.
Use market orientation to frame your shortlist, then compare vendors with criteria you can verify directly instead of relying on vendor messaging.
Build your scorecard around dimensions you can compare early: delivery model, connectivity model, and functionality depth. For delivery model, classify each vendor as local installation, hosted service, or Software as a Service (SaaS). For connectivity, evaluate where it sits on a traditional versus API-first model.
| Vendor | Delivery model (local / hosted / SaaS) | Connectivity model (traditional / API-first) | Functionality depth | Vendor-specific performance claims | Unknowns to log and verify |
|---|---|---|---|---|---|
| GTreasury | Verify | Verify | Verify | Unknown pending validation | Implementation effort, pricing, operating outcomes, country/program coverage, legal/compliance suitability, scenario-test results |
| Ripple Treasury | Verify | Verify | Verify | Unknown pending validation | Implementation effort, pricing, operating outcomes, country/program coverage, legal/compliance suitability, scenario-test results |
| Cobase | Verify | Verify | Verify | Unknown pending validation | Implementation effort, pricing, operating outcomes, country/program coverage, legal/compliance suitability, scenario-test results |
| Coupa Treasury & Cash Management | Verify | Verify | Verify | Unknown pending validation | Implementation effort, pricing, operating outcomes, country/program coverage, legal/compliance suitability, scenario-test results |
Treat unresolved unknowns as explicit selection risk, and record them before final vendor selection.
Use this as a practical sequencing model, not a universal template: establish visibility and reconciliation first, then add treasury actions. If your TMS, bank account management, and ERP integration are not producing a reliable cash view, adding pooling or FX actions can compound errors instead of reducing them.
| Phase | Scope | Gate or control | Evidence |
|---|---|---|---|
| Phase 1 | Use the TMS as the control layer before introducing new actions, while keeping current banks and payout routes in place | Bank events should be visible in the TMS, posted correctly into ERP, and explainable when timing differs | Daily control pack: opening cash and closing cash; in-flight settlements; unreconciled breaks by legal entity and currency |
| Phase 2 | Add cash pooling and tighter cash flow forecasting with constrained scope, such as one region, one currency group, or a small entity set | Define approval and rollback rules up front; if pooling introduces new reconciliation breaks or makes payout funding harder to explain at close, revert to the prior setup | Pilot evidence pack: approved transfer logic; bank confirmations; TMS execution logs; ERP postings; exception register |
| Phase 3 | Consider policy-driven investment management and advanced FX controls | If forecast confidence drops after routing, product, or banking changes, shorten decision windows and pause discretionary allocation until the cash view stabilizes | Policy detail teams can execute: allowable instruments; approval tiers; liquidity floor; maturity tracking; reporting treatment for principal and interest events |
Keep current banks and payout routes in place, and use the TMS as the control layer before introducing new actions. The target is one accurate cash view tied to bank and ERP records, not just better reporting.
Use a daily control pack to confirm readiness:
Treat ERP tie-out as a practical gate. Bank events should be visible in the TMS, posted correctly into ERP, and explainable when timing differs. If direct bank connectivity, aligned data, or workflow automation still feel bolted on, pause rollout and fix that before enabling additional automation such as sweeps or FX conversions.
A common next step is adding cash pooling and tighter cash flow forecasting after Phase 1 is operating reliably in your conditions. Start with constrained scope, for example one region, one currency group, or a small entity set, before broader automation.
Define approval and rollback rules up front:
If pooling introduces new reconciliation breaks or makes payout funding harder to explain at close, revert to the prior setup and classify the failure before expanding scope.
Keep a pilot evidence pack:
Consider policy-driven investment management and advanced FX controls once exception handling and close outcomes are consistently explainable in internal reviews. If forecast confidence drops after routing, product, or banking changes, shorten decision windows and pause discretionary allocation until the cash view stabilizes.
Set policy details teams can execute:
Apply the same standard to FX. If conversions or hedges cannot be traced through TMS records into close evidence without manual reconstruction, the control is not ready to scale.
In Gruv environments, map each phase to the modules carrying the cash signal, such as Virtual Accounts, Payouts, and MoR. Make balances, settlement states, retries, and approvals reviewable end to end before layering on treasury actions. Confirm repeated events do not create duplicate treasury actions and that the audit trail can show approval, execution, reversal, and ledger effect in one chain.
Include this implementation disclaimer: enablements and compliance gates vary by market and program and must be confirmed before launch. If coverage is unconfirmed, keep the phase scoped to visibility and manual approval until constraints are cleared.
Treat treasury as an operating chain, not a set of feature claims. If your TMS, ERP, and bank account data are not connected from cash visibility through reconciliation, you still have a visibility gap.
Liquidity is not just cash amount. It is timing and access. When reports are stale or cash is fragmented across entities, decisions degrade and you can end up borrowing in one place while unused cash sits in another. Keep one daily checkpoint visible by entity and currency, including opening and closing cash and key in-flight or unreconciled items.
For this operating model, one practical sequence is to establish clean cash visibility first, then add controlled cash pooling. Layer in cash flow forecasting once inputs tie back to actual cash movement, and place investment management after those controls are stable. The exact order can vary, but adding more moving parts before reconciliation is reliable can make breaks harder to explain.
Use one pre-launch checklist and require evidence for each item:
If any item is weak, narrow scope before expanding. A smaller rollout with reliable reconciliation gives platform finance teams better control than broad scope built on partial visibility. Before rollout, confirm country and program coverage plus compliance gates for your treasury design through Gruv contact.
At minimum, a treasury platform should cover cash and liquidity management, payment processing, and risk management. It should support domestic and international payments across multiple currencies. It also needs ERP integration, forecasting support, and audit trails that can be reviewed without manual reconstruction.
Cash pooling helps when teams can clearly see positions across accounts and reallocate liquidity to reduce stranded cash and borrowing pressure. It adds governance overhead when transfers, approvals, and reconciliations still rely on manual or fragmented processes. Expand in stages only as visibility, controls, and workflow reliability hold up.
Start with a current cash position and reliable data flow between the TMS and ERP. Refresh the inputs that move money, including known maturities, interest, principal settlements, and other material expected cash movements. Use connected bank, ERP, and payment-platform data, then reconcile forecast to actual each cycle.
Use a controlled payment workflow with clear status tracking, shared exception codes, and audit trails. Keep exception handling centralized, with clear ownership and visibility into whether cash moved, whether a customer was affected, and whether the ledger needs correction. Unresolved exceptions should stay visible in both the cash position view and the reconciliation pack until resolved.
Move idle cash only when the forecast is reliable and the cash position reconciles cleanly. Require approval ownership, decision logic, execution records, and a complete audit trail before execution. If reconciliation breaks or stale balances remain unresolved, pause discretionary investing.
Treat missing implementation detail as selection risk and record the unknowns before final vendor choice. Ask vendors to prove core workflows such as ERP data flow, payment handling across currencies, and audit-trail quality for normal and exception paths. If assumptions, country or program coverage, or operating outcomes are not demonstrated clearly, do not treat promises as delivered capability.
Harper reviews tools with a buyer’s mindset: feature tradeoffs, security basics, pricing gotchas, and what actually matters for solo operators.
Educational content only. Not legal, tax, or financial advice.
Move fast, but do not produce records on instinct. If you need to **respond to a subpoena for business records**, your immediate job is to control deadlines, preserve records, and make any later production defensible.
The real problem is a two-system conflict. U.S. tax treatment can punish the wrong fund choice, while local product-access constraints can block the funds you want to buy in the first place. For **us expat ucits etfs**, the practical question is not "Which product is best?" It is "What can I access, report, and keep doing every year without guessing?" Use this four-part filter before any trade:
Stop collecting more PDFs. The lower-risk move is to lock your route, keep one control sheet, validate each evidence lane in order, and finish with a strict consistency check. If you cannot explain your file on one page, the pack is still too loose.