A Coupa “exported” flag does not prove complete bank-file custody

Identify the original before moving the copy

Coupa's official documentation supports a narrow technical statement: Treasury Management can export selected original files to sFTP through standard or custom integrations. The custody record should begin before that export. Preserve the sending institution or channel, connection, receipt time, original filename, file type and format, message or statement identifier, byte count, checksum, encryption and signature result, source retention location, and parser status. If a file is compressed, bundled, decrypted, renamed, or normalized, retain the relationship between each derivative and the received bytes.

The documentation's distinction between bank files and account statements is operationally important because the former may not yet be assigned to a legal entity or account while the latter are assigned. Do not let a filename or folder infer that mapping. Record the rule and evidence used to associate the file with an institution, legal entity, bank account, currency, statement date, sequence, and reporting period, and route ambiguous or conflicting identifiers to an exception queue before balances or transactions enter a treasury view.

Separate selection, transfer, receipt, and use

An exported flag should mean exactly what the integration performed. Selection for a job, creation of an outbound object, placement in an sFTP folder, network transfer, target-side receipt, decryption, ingestion, validation, assignment, and downstream posting are different states. Preserve the job identifier and version, selection predicate, cutoff, source file identifiers, export time, outbound name and checksum, endpoint, transfer response, target acknowledgement, and any later processing result. A source-side state must not stand in for target custody.

Define when a file may be marked exported and what happens when the transfer fails after that state changes. Retry should reuse a stable identity so the target can detect duplicates without discarding a legitimate corrected file. If operators reset an export flag or manually copy a file, retain the action, reason, approver, prior attempts, and destination outcome. Access to original files and sFTP credentials should be separated and monitored, with no shared account able to alter source history and target evidence unnoticed.

Reconcile the population across the documented window

The Coupa documentation describes several standard exports using files received within the last seven days, including end-of-day and intraday statements, bank transaction reports, payment status reports, bank service fees, and PDF statements. A time-windowed job needs explicit cutoff and backfill controls. Reconcile files expected from channel schedules to files received, classified, selected, exported, acknowledged, ingested, assigned, archived, and processed. Include zero-file periods, late arrivals, overlapping runs, holidays, and retained failures in the population.

Test a file older than the selection window, two files with the same name, a corrected statement, a late intraday file, an unassigned account, a target acknowledgement followed by parse failure, an interrupted transfer, a manual replay, and an endpoint outage spanning the cutoff. The workflow should expose the gap, preserve the original and every attempt, backfill without duplication, and stop downstream completeness assertions until the exception is resolved. Counts alone are insufficient; totals and sequence continuity should be reconciled where the format supports them.

Read the documentation within its evidence boundary

The Coupa page establishes current official documentation for standard and custom original-file exports, file classes, selection conditions, and sFTP destinations. It does not establish a customer's bank-channel completeness, file authenticity, legal-entity assignment, endpoint security, successful target receipt, parser accuracy, statement completeness, reconciliation, settlement, accounting, archive, or recovery. Available job types, filters, schedules, naming, acknowledgement behavior, audit evidence, retention, and customer responsibilities require configured-environment confirmation.

Treasury Operations Review inspected the current official page on September 1, 2026, including its source HTML because the site's browser gate presented an unsupported-browser page. No dated material change after the August 31 successful-publication cutoff was established, so this is durable integration-control analysis rather than a current-intelligence event. Test one full file cycle—including late, duplicate, corrected, unassigned, and failed cases—from channel receipt through export, target acknowledgement, assignment, archive, downstream use, and recovery before relying on exported status.

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.