Bank Statements vs. Connected Bank Data: When to Use Each and How to Reconcile Overlap
The practical differences between PDF bank statements and Plaid-connected transaction data, and how to handle a file that includes both.
8 min read · Updated October 6, 2026
Two different sources of the same underlying facts
Lenders typically receive business bank activity through one of two channels: uploaded PDF bank statements (including scanned documents) or a live connection to the applicant's bank through a data provider such as Plaid. Both describe the same underlying account activity, but they differ in completeness, timeliness, and how much manual effort is needed to extract structured data.
PDF bank statements
Statements are the traditional submission format and remain necessary when an applicant's bank is not supported by a connection provider, when the applicant declines to connect live banking credentials, or when a lender's policy requires a document-based record for a specific product. Statements are a point-in-time, provider-generated document, which makes them useful as a fixed evidentiary record, but they require OCR or text extraction (especially for scanned statements) and can vary widely in layout from bank to bank, which makes consistent parsing harder.
Statements are also sometimes submitted selectively — an applicant might provide statements for one account but not a second account used for the same business, or might omit a period with activity they prefer not to show. A statement-only review can miss accounts that never appear in the submitted file.
Connected bank data
A live data connection retrieves structured transaction and balance data directly from the applicant's bank, typically covering a longer history, updating automatically, and including all accounts the applicant chooses to connect. Structured data removes the OCR step and generally gives cleaner, more complete transaction-level detail, including running balances.
Connected data has its own limits: it only covers what the applicant connects (an applicant can still omit an account from the connection), it depends on the bank's and provider's uptime and data quality, and some smaller institutions may have limited or no connectivity. Historical depth is also bounded by what the provider and bank make available, which may be shorter than a requested look-back period for an older or dormant account.
When to use each
A practical approach many lenders use: request a connection as the default path because it reduces manual document handling and extends usable history, but accept and analyze statements when a connection is unavailable, declined, or needed to fill a gap (for example, an account the applicant will not connect, or a period the connection doesn't reach). Some lenders require statements as a verification or policy backstop even when a connection exists, to confirm bank identity and account ownership matches the application.
Reconciling overlap
When a file includes both a connection and statements for the same account and period, the data should be reconciled rather than simply combined, to avoid double-counting deposits or financing positions. A practical reconciliation checks: the account and routing identifiers match between sources; the statement period and connected-data date range are aligned or clearly distinguished; transaction counts and total deposits/withdrawals for the overlapping window are compared for consistency; and any discrepancy (for example, a transaction present in one source but not the other) is flagged for review rather than silently resolved in favor of one source.
In practice, discrepancies often come from timing — a connection might show a transaction as pending while the statement shows it posted on a different date — or from a statement covering a slightly different period boundary than the connected window. Treating the more complete, most recently verified source as primary for the overlapping period, while retaining the other as a cross-check, is a reasonable default policy, but it should be documented and applied consistently.
Reviewer guidance
When a file has both sources, a reviewer should confirm which source was treated as primary for any overlapping period and why, check that flagged discrepancies were actually resolved (not just noted), and verify that accounts present in only one source were still included in the overall picture rather than dropped because they weren't in the 'primary' source.
See how LendLucid handles this in practice.