Verified against ChatGPT · 2026-08-11
Turn a rambling walkthrough of how someone actually does a finance task into a written SOP
Converts an unstructured description of how a finance process actually gets done today into a step-by-step SOP with explicit exception handling, so the process survives the person who currently holds it in their head leaving.
The prompt
Ready to copy — highlighted parts are example details you can swap.
I'm going to describe, in my own unstructured words, how a finance process actually gets done today — not how it's supposed to work on paper, but what actually happens, including the workarounds. Turn this into a proper SOP document. PROCESS NAME Monthly credit card expense reconciliation MY RAW DESCRIPTION OF HOW IT ACTUALLY WORKS So every month around the 3rd I pull the card statement, then I go through it line by line against the receipts folder, and honestly for the ones under $25 I usually just approve them without checking because it's not worth the time, then I email finance the total, and if something looks weird I just ask the person directly over Slack instead of going through the formal dispute process WHO CURRENTLY DOES THIS Me, as ops manager — nobody else has ever done this end to end SYSTEMS INVOLVED Amex portal for statements, a shared Google Sheet for tracking, Slack for questions, QuickBooks for the final entry STEP 1 — Extract the actual sequence. Read through my raw description and pull out the real sequence of steps in order, including any manual workarounds I mentioned (a spreadsheet someone maintains outside the system, a step someone does from memory) — do not clean these workarounds out of the process or silently replace them with how the process "should" ideally work; document what actually happens, since the point of this SOP is that someone else can do exactly what the current owner does, workarounds included, until those workarounds are deliberately fixed. STEP 2 — Flag ambiguity. Wherever my description was vague about a step (I said something like "then I just check it looks right" without saying what "right" means), do not invent a specific definition — list it as an open question I need to answer before this SOP is complete, with the specific clarifying question. STEP 3 — Exception handling. Ask me, or infer from what I said, what typically goes wrong in this process and what the current owner does about it — a SOP that only covers the happy path is unusable the first time reality deviates from it, which in a finance process is often. STEP 4 — Structure. Write the final SOP as: Purpose (one sentence), Trigger (what starts this process), Numbered Steps (each with the system/tool used and roughly how long it takes), Exception Handling (what to do when X goes wrong), and Owner/Backup (who does this and who covers if they're out). WHAT NOT TO DO Do not smooth an odd or inefficient step out of the documented process without flagging it — flag it as a note for future improvement, but still document what currently happens, since replacing it with your own idea of best practice would make the SOP inaccurate to reality. OUTPUT FORMAT The structured SOP per Step 4, followed by an "Open Questions" list from Step 2, and a separate "Improvement Ideas (not yet implemented)" list of anything you noticed that seemed inefficient — clearly separated so it's never confused with the documented current process.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The instruction to document workarounds as-is rather than cleaning them into an idealized version of the process is the single most important structural choice here, because the entire point of an SOP written from a tribal-knowledge interview is continuity — someone else needs to be able to do exactly what the current owner does, including the informal under-$25 shortcut and the Slack-instead-of-formal-dispute habit, or the document is describing a process that doesn't actually exist and will fail the first time a successor tries to follow it literally. Separating flagged ambiguity into an explicit "open questions" list rather than letting the model quietly resolve it addresses a specific and risky behavior: when a raw description is vague ("I just check it looks right"), a language model asked to produce a clean SOP will confidently fill that gap with a plausible definition of its own invention, and a reader of the finished SOP has no way to tell that step was fabricated rather than reported — surfacing it as a question the actual process owner must answer keeps the document honest about where real information ends. Requiring exception handling as a mandatory section, not an afterthought, matters specifically for finance processes because reconciliation, approvals, and expense processes deviate from the happy path constantly in practice, and a SOP that only documents the clean-run sequence becomes useless during the first real anomaly, which is exactly when a written procedure is needed most. Keeping "improvement ideas" in a strictly separate list from the documented current process prevents the common failure where a well-intentioned rewrite quietly upgrades an inefficient real practice into a better-sounding hypothetical one, producing a document that reads well but doesn't match what actually happens on the ground.
What you get back
Step 4 (Reconciliation): Pull the Amex statement from the portal (~10 min). Cross-check each line against the receipts folder; items under $25 are approved without individual receipt-matching as a time-saving practice (flagged below as an improvement candidate). Email finance the reconciled total. Open Question: what does "looks weird" specifically trigger checking for — a merchant category mismatch, an amount outlier, or something else? Improvement Idea (not yet implemented): the under-$25 auto-approval and the informal Slack-based dispute resolution bypass the formal dispute process — worth a controls review, but currently documented as-is above.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — 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
