The Bank Feed Broke. I Still Didn’t Put the Fix Inside the Document Request

I kept bank-feed diagnosis, client document collection, and reconciliation as separate responsibilities so one missing-statement request would not quietly become accounting software.

A bank feed stops syncing.

The last transaction visible in the accounting system is July 14.

Before asking the client for anything, someone has to answer a very specific question:

What dates are actually missing?

That sounds like a document-request problem because the next step may be asking for a bank statement.

It is not.

The missing period comes from the accounting system and the bookkeeper’s investigation. I wanted the document request to start only after that boundary had already been established.

Otherwise the request tool would slowly become responsible for diagnosing the bank connection, choosing an import range, detecting overlap, and eventually deciding what belongs in the ledger.

That is a much larger product.

Start the request with a known gap

For one disconnected account, the useful context might be:

Bank: Northside Bank
Account: Operating ••4821
Last successful sync: July 14
Missing period: July 15–31

The request layer can preserve those values.

It should not invent them.

If the accounting system shows July 14 as the last successful transaction date, the bookkeeper can determine whether July 15 is really the beginning of the gap and whether the entire rest of the month needs source documentation.

Only then does the client request have a clear job:

Requested item:
Official statement covering July 15–31

That is much better than sending:

Please send your latest bank statement.

The broader wording looks easier to generate, but it moves the investigation onto the client and makes the later review harder.

For this workflow, I kept the requested account, masked last four digits, missing-period start, missing-period end, due date, and handoff owner visible as request context.

The source file solves one problem

Once the missing period is known, the request can ask for the source document that matches it.

Often that means an official statement PDF.

In some cases the external accounting process may actually need a CSV transaction export instead. The choice belongs to the bookkeeping work that happens after collection, so the request needs to say exactly which file is wanted rather than treating PDF and CSV as interchangeable.

I used that boundary in the bank feed disconnected statement request workflow.

The page begins with the accounting system identifying the gap, then moves into one account-specific document request.

That sequencing matters.

The uploaded statement can help fill the missing source-document gap.

It does not reconnect the bank.

It does not import the transactions.

It does not reconcile the account.

It does not prove which transactions will eventually need to be manually imported.

Those are separate decisions even though they all started with the same broken feed.

Review should answer whether the file is usable

The document layer still has real work to do after upload.

Staff can check:

• whether the account matches;
• whether the period covers the requested gap;
• whether the file opens;
• whether a password prompt blocks review;
• whether expected transaction pages appear to be present;
• whether the upload is obviously the wrong period, wrong account, incomplete, duplicated, or unreadable.

Those checks are enough to decide whether the requested item can move forward or needs a replacement.

They are not enough to decide whether the statement is authentic in some absolute sense or whether every transaction in it belongs in the accounting system.

That difference keeps the review action narrow.

A wrong-period statement can stay unresolved and receive a specific replacement request.

A usable statement can become Received after staff review.

At that point, the document request has completed its job.

The accounting work still has not.

Reconnection creates a new problem outside the request

The awkward case happens when the bank feed comes back.

Suppose the client has already supplied a July 15–31 statement, and someone is considering a manual transaction import.

Then the restored feed also starts bringing in transactions from July 25 onward.

Now there may be overlap.

The document request can preserve useful context for that moment:

Last successful sync: July 14
Requested period: July 15–31
Source file reviewed: July statement
Possible restored-feed overlap: check before manual import

But I do not want the request itself deciding:

Import only July 15–24.
Drop these eight duplicates.
Reconcile this balance.
Post this adjustment.

Those decisions require information and accounting responsibility that the collection layer does not own.

Keeping the dates in the handoff note is useful.

Turning that handoff note into a duplicate-transaction engine would be a scope change.

The handoff is a product boundary

This is the part I would rather make explicit than hide behind an integration.

The accounting system knows the connection and transaction history.

The document-request layer knows which source file was requested, uploaded, reviewed, rejected, replaced, or accepted.

The bookkeeper decides what the usable file means for import, overlap, reconciliation, and accounting treatment.

The same client and bank account can appear in all three places without one product needing to own every step.

For a small tool, that boundary removes a surprising amount of accidental complexity.

If the bank feed breaks, the document request does not need to fix the feed.

It needs to make sure the bookkeeper gets the right source document for the exact gap that was already identified.