Skip to main content
2,200+ service businesses benchmarked. Do you know your gross profit per labor hour? See where you stand →
Level

Software collection playbook

Chase: verify account identity and statement scope

Reconnect account identity and complete coverage.

By Sam Yang · Updated

Is this the right account and the right kind of movement?

First choose checking, card or loan evidence. Then bind the intended masked account and period. A successful login alone does not identify which business or account is open.

Evidence basis: Saved statement and account-selection observations; availability of specific download routes must be checked in the current session. Some checks restate Level review safeguards (code rules, not observed vendor behavior).

Verify the intended QBO feed mapping and statement coverage for this specific bank account and period.

The owner is reconciling a checking account

Use its statement movement and dates against that ledger account; preserve distinct same-amount occurrences.

The owner is reviewing a card program

Determine whether master and subcard views overlap before adding their activity. A payment to the card and the underlying purchases need separate treatment.

Use supported API or native report access for the required scope. A permitted browser session can collect a specific gap. Neither route proves reconciliation or complete costs.

Put the evidence to work

Chase is connected to QuickBooks. Why is the new account still hard to reconcile?

A working connection is transport. The close still needs the right legal account, the right ledger destination and uninterrupted statement coverage. Start with those identities. Reconnecting before checking them can make an overlap or mapping problem harder to explain.

Review the mapping of a newly added Chase account
  1. Identify whether the source is checking, savings, a credit card or a loan. Retain the legal holder and masked account suffix from the actual statement.
  2. List the intended QBO ledger account and any existing accounts with similar names. Compare type and masked identity; display name alone is not sufficient.
  3. Collect the first complete statement and the overlapping last statement or activity period from the prior route. Identify the first and last observed transaction dates.
  4. Compare independent bank occurrences with booked activity and pending feed items. Keep imported, posted and pending states separate.
  5. Return mapping conflicts and coverage gaps as a worklist. Record the proposed destination for review without reconnecting or changing the account.

Bring to the review: A mapping record with source holder/type/suffix, proposed ledger ID, coverage start/end and overlap exceptions.

Then decide: Fix a demonstrated identity or coverage problem through the approved owner workflow. Do not interpret connection success as acceptance of the ledger mapping.

Keep card activity separate from the payment that settles it
  1. Identify the primary card statement and any employee-card views. Determine whether those views overlap the primary account population.
  2. Retain statement opening liability, purchases, fees, credits, payments and closing liability. Verify extracted section totals against the statement.
  3. Identify individual purchase occurrences once, using the issuer reference where available. Keep view labels even when the same event appears twice.
  4. Trace the payment out of checking and its reduction of card liability separately from purchases. Investigate different posting dates across the two sources.
  5. Explain any unpaired payment, credit or reversal. Keep unsupported transaction pairings open even if the statement summary arithmetic agrees.

Bring to the review: A statement liability bridge and a checking-to-card payment trace, with overlapping source views identified.

Then decide: Use the purchase evidence to review costs and the payment evidence to review settlement. Counting both as expense would misstate the economics.

Which collection route answers this question?

Choose the route for the missing evidence and the access available in your account. The comparison below distinguishes documented coverage from coverage that still needs checking.

Existing Chase-to-QBO connection

What it supplies
Chase and Intuit describe authorized financial-data sharing. A specific connection can supply activity for its approved account scope.
What still needs proof
Neither the public description nor a connected tile proves that all historical statements arrived or that the chosen ledger account is correct. No general-purpose Chase API entitlement is asserted here.

Choose it when: Use the established connection when its account mapping and observed coverage have been independently checked.

Statements and authorized activity files

What it supplies
Chase provides statement and account-management support. Statements establish account, period and summary controls; an available activity file can supply line detail.
What still needs proof
Download formats, date windows and administrator access depend on the current account route. A transaction export is not automatically the same population as a closed statement.

Choose it when: Use original statements for controls and verified activity detail to investigate missing or repeated occurrences.

Permitted browser collection

What it supplies
Saved observations support account-identity checks and a statement-document route that may work when a dashboard shows an account-setup error.
What still needs proof
That fallback is a dated observation, not a guarantee for every account. A local file-save error is not evidence of a bank-imposed download restriction.

Choose it when: Use the actual authorized bank session for a needed statement or native detail, checking the rendered holder and account before collection.

Reproduce the diagnostic

A card payment changes liability, not the purchase total

All records and amounts below are fictional teaching inputs. This example demonstrates the calculation, not a customer outcome or a reproduced software defect.

Card movement is 600 + 20 - 800 = -180, so closing liability is 1,000 - 180 = 820. Purchase/fee candidates total 620. Adding the 800 settlement again would turn 620 into an unsupported 1,420 cost figure.

What the CSV columns mean
  • All rows are fictional teaching data in USD, not a customer statement or native Chase schema.
  • liability_delta increases amounts owed when positive and reduces amounts owed when negative. opening_liability is 1,000.
  • operating_cost_candidate is a teaching classification for purchases and fees only; it does not decide capitalization, business purpose or tax treatment. Checking settlement is supplied separately.
Card liability movement
-180 USD
Closing liability falls by 180.
Closing liability
820 USD
Opening 1,000 plus movement -180.
Purchase and fee candidates
620 USD
Still subject to accounting classification.
Checking payment
-800 USD
Linked settlement reduces card liability, not another purchase.
Inspect card-bridge.csv
event_id,event_kind,liability_delta,operating_cost_candidate
C-01,purchase,600,600
C-02,fee,20,20
C-03,payment,-800,0
Download this CSV
Inspect checking.csv
event_id,event_kind,amount,linked_card_event
K-01,card_payment,-800,C-03
Download this CSV
Inspect controls.csv
control,value
opening_liability,1000
Download this CSV

Next decision: Review the classification of purchases and fees, and validate the supplied payment link with original evidence in a real case. A zero payment difference alone would not establish that link.

Run the example locally

Save the CSV files, expected-results.json and reproduce.mjs in one folder. With Node.js installed, run the command below. It calculates the checks from the CSV bytes and rejects a changed input or expected result.

node reproduce.mjs expected-results.json

No software login, customer records or API key is required.

When the result does not make sense

The dashboard displays an account-setup error.

Check: Check whether the authorized statement/document area opens for the intended masked account. A dashboard error and statement access are different outcomes.

Resolve the question: If the statement is available, retain it and label the working route. If identity or access is uncertain, ask the owner for that exact statement rather than collecting another account.

Card spend increases after combining employee-card downloads.

Check: Compare primary-statement and employee-view occurrence references. Look for overlapping views before assuming extra spend.

Resolve the question: Keep a unique-occurrence table with source-view provenance; preserve originals instead of discarding an entire view.

A card payment appears as an expense in checking and card purchases are also expensed.

Check: Trace the payment against the card liability and distinguish purchase, fee, interest and settlement components.

Resolve the question: Prepare a specific classification issue for accounting review. Do not assume every same-value debit is the card payment or treat the whole payment as a new operating cost.

Where automation earns its place

Good work for automation

  • Statement inventory, account-suffix checks, continuity controls and overlap worklists help keep a new-account close repeatable. Browser collection can recover a needed source file when an authorized native route is available.

Keep a person on these decisions

  • The reviewer establishes the legal holder, ledger mapping, genuine versus overlapping occurrences and economic treatment of card payments. Browser automation does not approve reconnects or account merges.

References behind these workflows

Product documentation supports the specific scope stated beside each source. Level's diagnostic methods and fictional calculations remain distinct from vendor capabilities.

Explore the financial diagnostic examples

Collect and verify the population

Rendered account identity
Check account kind and masked identity against the intended ledger mapping.
Statement and native activity
Retain original bytes, opening/ending movement and the requested period.
Alternate authorized document route
If a dashboard view fails, check available statement access before declaring collection unavailable; a local save failure is a separate problem.

Select the correct bank account and statement period; retain original downloaded bytes. Compare account kind and masked identity with the intended ledger account, then verify statement movement and missing dates.

Evidence acceptance checklist

  1. Confirm account type and masked identity against the intended ledger account.
  2. Retain original statements for every requested period.
  3. Distinguish account-level and subcard views before counting transactions.

Fictional collection example

A fictional card program includes a parent statement and employee card views. The same charge may appear in more than one view. Return account and transaction identity before combining them. A same-value charge on another date remains unresolved until its occurrence is established.

Invented teaching scenario, not a customer result or a reproduced vendor defect.

Capture the setup with the evidence

  • Company, legal entity or account, report name, period, basis, currency and timezone.
  • Selected filters, status, page count, original record identifiers and control totals.
  • Collection time, source route and authorized role. Record browser and automation versions when using a browser.
  • Original files and exceptions. Keep credentials, customer identifiers and financial artifacts private.

A browser version helps reproduce an interface issue. It does not validate the financial conclusion.

Pitfalls and stop conditions

Checking, card and loan statements have different financial meanings. Card-program and subcard views can overlap. A local save failure does not establish a bank restriction. Same-value rows need distinct transaction evidence.

How a plausible answer can go wrong

Adding a card program total and overlapping subcard totals can count the same purchases twice. Mapping a correctly downloaded statement to the wrong ledger account remains a bad collection result.

Stop if account identity, permission, cutoff or population is uncertain. Return the missing evidence for review. Do not fill the gap with an invented record, a balancing entry or an assumed zero.

Read-only AI collection prompt

Replace the bracketed scope before use. This prompt collects evidence; it does not permit edits, approvals or accounting execution. Requesting an emailed report is a separate account action and requires explicit authorization.

Collect read-only evidence for Chase checking and cards to answer [financial question]. Confirm [company], [account/entity], [period], [basis], [currency] and [allowed reports]. Select the correct bank account and statement period; retain original downloaded bytes. Compare account kind and masked identity with the intended ledger account, then verify statement movement and missing dates. Retain original files, complete record IDs, counts, filters, collection timestamp and exceptions. Checking, card and loan statements have different financial meanings. Card-program and subcard views can overlap. A local save failure does not establish a bank restriction. Same-value rows need distinct transaction evidence. Stop if the source or scope is uncertain. Do not post, match, reconnect, delete or change settings. Return the evidence for financial review; do not claim the books are correct. Do not approve, submit payroll, pay, transfer, refund, send messages, invite users or accept terms. Stop at any login, MFA or credential prompt and hand back to the account owner. Store files only in [approved private location]. Do not paste customer artifacts into public tools. Use only preauthorized collection actions. Request an emailed report only when its delivery is explicitly authorized; otherwise ask the account owner to supply the file.

Next decision

What does the evidence support?

Can the bookkeeper identify which account the file belongs to and explain its movement without overlapping views? Resolve identity and coverage before reconnecting feeds or assigning accounting categories.

Compare the same population, identities and cutoff. Keep unsupported costs or settlements visible before using the result for pricing, cash or close.

Open the financial acceptance guide →

Sources and scope

Base product-reference scopes were reviewed . No end-to-end dated native UI walkthrough is published for this software. Individual source rechecks are dated with their citations. Operator decision guidance was reviewed 2026-10-07. The references below support their stated product scope, not every observed interface detail. It is not a vendor capability certification, a measured customer result or an independently reconciled account. Verify current features and entitlement in the account you use.

Content revision history