Month End Close Evidence Request Board for Distributed Teams

A month end close evidence request board coordinates inputs to accounting work. It should show which reconciliation, schedule, report, or explanation is needed; the period and entity it supports; who prepares it; and who accepts it for the close. It should never present itself as the ledger or let a progress label substitute for review.

Design the board around close dependencies

Map the close sequence first. Bank activity may feed cash reconciliation, subledger reports may feed control account review, and accrual support may depend on operational estimates. Give every request a close task identifier so one uploaded file is not mistakenly counted against several unrelated tasks.

Board field	Operational use	Evidence boundary
Period and entity	Prevent cross period reuse	Must match source report
Request type	Names schedule, report, or explanation	Does not prescribe accounting conclusion
Dependency	Shows what cannot start yet	Requires attributable completion event
Reviewer	Identifies acceptance authority	Coordinator cannot self approve

Create recurring requests from the approved close checklist, then allow period specific additions with an owner and reason. Record the due time and time zone. A request copied from last month should still be checked for current accounts, systems, and preparers.

Make every upload self identifying

A submission note should state source system, report or schedule name, parameters, as of time, preparer, and file version. For reconciliations, link the governed working paper rather than attaching uncontrolled copies to many board cards. For explanations, preserve the person and date behind the statement.

NIST SP 800-92 provides guidance on computer security log management. Although a close board is not a security log program, its discussion of reliable timestamps, sources, retention, and review supports disciplined event records. Accounting evidence requirements remain with finance policy and qualified accounting owners.

Run review as a return loop

Submitted, under review, returned, and accepted should be separate states. A return note names the exact missing item or inconsistency and leaves the prior version visible. Resubmission increments the version and links the response. Only the role named in the close policy marks the request accepted.

Use exception lanes for inaccessible systems, unreconciled differences, late external statements, and disputed ownership. These categories have different remedies. A single overdue label hides whether the team needs technical access, an accounting decision, or a third party document.

Bookkeeping assistant support can maintain requests and package source data within approved access. The month end close request intake guide covers how ad hoc requests enter the recurring close.

Conduct a daily dependency review

During close, review work that blocks another task, returned submissions, aging external inputs, and requests without an accountable reviewer. Avoid reading a percent complete figure as a forecast. Ten easy uploads can be complete while one bank reconciliation blocks financial review.

After close, reconcile accepted board items to the approved checklist and final working paper index. Sample whether period, entity, source parameters, version, and acceptance are reconstructable. Archive or retain board records under finance policy and remove unnecessary duplicate evidence from collaboration spaces.

Start with one close cycle and a small dependency map. Compare planned requests with actual review returns. Use those returns to improve instructions and ownership for the next period rather than adding generic fields to every request.