Verified against ChatGPT · 2026-08-12
Build a month-end close checklist that shows which steps block which, not just a flat list of tasks
Produces a month-end close checklist organized by dependency and owner rather than a flat task list, so the close doesn't stall on day six because someone didn't realize their step was blocking three others.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a month-end close checklist for our finance team. I don't want a flat list of tasks in no particular order — I want the dependency structure made explicit, because our close has stalled before when someone didn't realize their step was blocking three other people's steps.
TEAM AND ROLES
Controller, AP lead, AR lead, and a part-time bookkeeper who handles bank reconciliation
CURRENT CLOSE TASKS (as I know them)
Reconcile bank accounts, close AP subledger, close AR subledger, review accruals, run trial balance, review with controller, post adjusting entries, finalize P&L
CLOSE TIMELINE TARGET
5 business days target, currently taking 8
KNOWN PAST BOTTLENECKS
Accrual review has stalled twice waiting on department heads to confirm open POs; trial balance review with the controller has been delayed because it's scheduled before AR close finishes
For every task, state: the owner, what it depends on being finished first (name the specific upstream task, not just "earlier steps"), what depends on it being finished (downstream tasks that are blocked until this is done), and a rough duration. Organize the output as a dependency-ordered sequence, not an alphabetical or category-ordered list — tasks with no dependencies should be clearly identifiable as things that can start on day one in parallel. Where I've named a past bottleneck, trace it to the specific task in this list and note explicitly why it became a bottleneck (was it blocked on something upstream, understaffed, or a task that reliably takes longer than budgeted) and propose one specific change to prevent it recurring, not a generic "communicate better" suggestion.
WHAT NOT TO DO
Do not invent a dependency between two tasks that wouldn't actually block each other just to make the chart look more connected — if a task genuinely has no upstream dependency, say so plainly. Do not assign a duration with false precision ("47 minutes") — use a realistic range and note it should be calibrated against your team's actual historical timing, not treated as a fixed benchmark.
OUTPUT FORMAT
1. A dependency-ordered table: Task | Owner | Depends On | Blocks | Duration.
2. A short "can start immediately" list of zero-dependency tasks.
3. A "bottleneck fixes" section addressing each named past bottleneck specifically.
4. One line noting this checklist should be validated against your actual close cycle before being treated as final process.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Requiring an explicit upstream dependency and downstream blocked-list per task, rather than a flat sequential checklist, is what actually diagnoses why a close stalls — a flat list makes every task look equally sequential even when several could run in parallel, which either falsely compresses the timeline (nobody notices a real blocking dependency) or falsely extends it (tasks that could run simultaneously get scheduled one after another out of habit); making dependency explicit surfaces both problems in the same structure. Tracing each named past bottleneck to a specific task and classifying why it became one (blocked upstream, understaffed, or a task that structurally runs long) rather than accepting a generic "communicate better" fix forces a real diagnosis: the example given — trial balance review scheduled before AR close actually finishes — is a scheduling-order bug, not a communication problem, and only naming the actual mechanism produces a fix that would prevent recurrence rather than a platitude that changes nothing. The instruction against inventing false dependencies matters because a model asked to build a dependency chart has an incentive to make the chart look complete and interconnected, and a fabricated dependency between two genuinely independent tasks would wrongly serialize work that could run in parallel, directly working against the stated goal of compressing an 8-day close to 5. Refusing false-precision durations ("47 minutes") while still requiring a duration estimate keeps the checklist honest about what's a real, calibratable estimate versus what would be spurious specificity dressed up as data — a range invites the team to validate against their own historical timing, while a fake-precise single number invites false confidence in a number that was never measured.
What you get back
Task: Accrual review | Owner: Controller | Depends on: department heads confirming open POs (currently unscheduled as its own task — this is the bottleneck) | Blocks: trial balance run | Duration: 1-2 days once inputs arrive. Bottleneck fix: add a standing day-2 deadline for department heads to confirm open POs, owned by the controller chasing it directly rather than waiting passively, since the current stall is an upstream input problem, not a review-capacity problem.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
