A partial-month request needs exact coverage, but the source document does not always need the exact same start and end dates.
A bookkeeping request covers:
May 1–18
The client uploads an official bank statement covering:
May 1–31
A strict date check can make that look wrong:
uploaded_range != requested_range
→ reject
But the statement may contain every day the bookkeeping team asked for.
The request is partial-month.
The source document does not have to be.
That distinction changed how I thought about validating files for partial-period bookkeeping requests.
Exact request dates do not require exact document dates
The request still needs a precise boundary.
For example:
Client: Westline Workshop
Exact start date: May 1
Exact end date: May 18
Reason: bookkeeping handoff
Those dates tell the team which part of the client’s activity belongs to this collection task.
They do not redefine how the bank produces statements.
If the bank issues one statement for May 1–31, the client may not have an official document ending on May 18.
Rejecting that statement only because its end date is May 31 would confuse two different questions:
What period does the request need covered?
and:
What period does this source document naturally contain?
The first should be exact.
The second may be broader.
Coverage is a better test than equality
The naive rule is easy to write:
document_start == request_start
document_end == request_end
For some reports, that may happen to work.
It is not a safe universal rule.
For the May 1–18 example, the useful question is closer to:
Does this source document cover
the requested May 1–18 period?
A May 1–31 statement can answer yes.
A May 10–31 statement cannot fully answer yes, because May 1–9 is still missing.
A March–May quarterly sales report may contain the requested dates, but staff may still need to decide whether that report is the source they actually asked for.
That is why the partial-month bookkeeping document request checklist keeps date range, source coverage, and requested item as related but separate pieces of context.
The request should describe the evidence needed.
It should not assume every provider produces evidence in exactly the same date shape.
Generating another export can create a second problem
There is a tempting fix when the statement is broader than the requested range:
Ask the client for a CSV from May 1–18.
Now the dates match perfectly.
That still may be the wrong request.
The page explicitly avoids treating a date-range export as mandatory for every partial period. If the statement already supplies the needed factual coverage, an extra export may add another file without solving a real gap.
Now staff may receive:
May bank statement
May 1–31
and:
Transaction export
May 1–18
The team then has two sources around the same activity and another question to resolve:
Which one is the requested evidence for this item?
A narrower file is not automatically a better file.
The responsible bookkeeping workflow still decides whether the statement is enough or whether a transaction export is actually needed.
The document-request layer should preserve that decision instead of inventing a universal “partial month requires CSV” rule.
A handoff date makes the failure easier to see
Partial-month requests often appear because responsibility changes in the middle of a month.
Suppose bookkeeping responsibility changes on May 18.
The request may need records for May 1–18, plus opening, ending, or handoff context where relevant.
Some source records naturally cross that boundary.
A monthly statement may continue through May 31.
A payroll cycle may begin before May 18 and end after it.
An invoice or source document may relate to activity on both sides of the handoff.
The checklist explicitly allows records that cross the handoff date to be requested with the relevant source context instead of pretending the source itself must be cut into artificial pieces.
That means a reviewer needs to distinguish:
broader source document that covers the requested period
from:
wrong-period document that misses required dates
They can look similar if validation only compares date labels.
They are not the same failure.
Do not automate a professional cutoff decision
There is also a boundary I would keep out of the validator.
Suppose the statement covers May 1–31 and the request is May 1–18.
The document layer can record:
Requested period: May 1–18
Uploaded source: May 1–31 statement
Coverage: includes requested period
It should not automatically decide which May 18 transactions belong to one bookkeeper, whether an accrual belongs before or after the handoff, or whether the accounting is complete.
Those are accounting decisions.
The page is explicit about that boundary: CollectCue organizes exact dates, requested records, uploads, review context, reuploads, and follow-up; it does not decide cutoffs, accruals, journal entries, reconciliation, pricing, or accounting completeness.
That keeps the validation problem much smaller.
The product can help answer:
Does this file provide the requested factual coverage?
It does not need to answer:
What accounting result should come from that coverage?
Reject missing coverage, not harmless extra coverage
For a partial-month request, I still want exact dates everywhere the team needs them.
The request should clearly say May 1–18.
The reviewer should be able to see May 1–18.
A replacement request should say exactly which dates are still missing.
But I would not make exact date equality a universal acceptance condition.
A May 1–31 statement can contain the right May 1–18 evidence.
A May 10–31 statement cannot.
The difference is not whether the dates match perfectly.
It is whether the requested period is actually covered by the right source.
That is the failure I would design around before adding automatic date validation.
Top comments (0)