Introduction
Desktop procedures — sometimes called desk procedures or desktop instructions — are role-level documents that explain exactly how one person performs a specific task at their desk: which system to open, which menu path to follow, which fields to complete, and what to do when something does not match. They are the workhorse documentation of finance, accounting, payroll, and back-office operations, and they are what an auditor means when they ask how a control is actually performed rather than what the policy says.
They are also chronically missing. Panopto's Workplace Knowledge and Productivity research found employees spend around five hours a week on average waiting for or recreating knowledge held by colleagues, and Protiviti's annual SOX Compliance Survey consistently identifies process documentation as one of the major drivers of compliance effort. Both problems have the same cheap remedy: the person who does the task writes down, once, exactly how it is done.
This guide defines desktop procedures, distinguishes them from SOPs and work instructions, and walks through writing one — including a worked example for processing a vendor invoice in an ERP.
What Desktop Procedures Are — and Why They Matter
A desktop procedure documents a single recurring task from the perspective of the person performing it. Classic examples: posting the daily cash receipts, running the weekly payroll file, reconciling a bank account, processing a vendor invoice, generating the month-end accrual report. The defining features are granularity and specificity: real system names, real menu paths, real report codes, screenshots of real screens (with sensitive data masked), and the actual keystrokes — not a general description of the process.
Three forces make them valuable. First, auditors: external auditors and SOX programs ask for desktop procedures as evidence that key controls are performed consistently and that the documented control matches reality. Second, continuity: when the accounts payable specialist wins the lottery or simply takes two weeks off, the desktop procedure is the difference between a colleague covering the desk and invoices piling up. Third, onboarding: a new hire with a good set of desk procedures is productive in days rather than months.
Desktop Procedures vs SOPs vs Work Instructions
The three terms overlap, and different organizations draw the lines differently, but a practical distinction holds. An SOP describes a process at the team or department level — the accounts payable process from invoice receipt to payment, including roles, controls, and handoffs. A desktop procedure zooms into one role's tasks within that process — how this specialist enters and matches an invoice in this ERP, click by click. Work instruction is the manufacturing-world cousin of the desktop procedure: task-level, single-role, at the workstation instead of the desk. In short: SOPs say who does what and when; desktop procedures say exactly how one person does their part. You need both, and each should reference the other.
What to Include in a Desktop Procedure
1. Header Block: Task, Owner, and Review Date
Start every desktop procedure with a header: task name, the role (not the person's name) that performs it, the systems involved, frequency and deadline (daily by 10:00, business day 3 of close), the owner responsible for keeping it current, the last-reviewed date, and the version. The review date is the honesty mechanism — a desk procedure last touched three systems ago is worse than none, because it is confidently wrong.
2. Purpose and Trigger
Two or three sentences: what this task accomplishes, what triggers it (a schedule, an email, a queue reaching a threshold), and what depends on it downstream. This is what lets a cross-trained colleague judge urgency and consequences when covering the desk.
3. Systems, Access, and Prerequisites
List every system touched, the access role or permission required, where to request access, and any prerequisites — files that must exist, jobs that must have run, approvals that must be in hand. Nothing derails a continuity plan faster than discovering at 9 a.m. that the backup person has never had a login.
4. Exact Steps: Clicks, Paths, and Fields
The body is a numbered list, one action per step, using the real names on the screen: the module, the menu path written out (Accounts Payable, then Invoice Entry, then Standard Invoice), the fields in the order they are completed, the values or where the values come from, and what the screen should show if the step worked. Write for a competent colleague who has never done this task — not for the expert who wrote it.
5. Screenshots and Annotations
Add a screenshot at every step where the screen is busy or the right control is easy to miss, with an arrow or box marking the target and dummy or masked data throughout — no real vendor bank details, employee data, or customer information in a document that will be widely shared. Screenshots are also your early-warning system: when the screenshot stops matching the screen, the procedure is due for review.
6. Exception Handling and Decision Rules
The steps cover the clean path; the value is in the exceptions. Document the common ones as simple rules: if the invoice does not match the purchase order beyond tolerance, do this; if the vendor is not in the master file, request setup via that form and park the invoice; if the batch fails to post, check this log first. Every exception rule ends in either a resolution or a named escalation.
7. Controls, Approvals, and SOX Touchpoints
Flag every step that is a control: matching, approval thresholds, segregation-of-duties boundaries (the person entering the invoice cannot also approve payment), and the evidence the control leaves behind. For companies under SOX, this is exactly the material that supports control testing — and keeping it inside the desktop procedure means the documented control and the performed task cannot drift apart unnoticed.
8. Contacts and Escalation
End with a short table: the task owner, the backup, the system administrator, the approver, and the escalation contact for each major exception — by role and team inbox rather than personal names where possible, so the document survives staff changes.
A Worked Example: Processing a Vendor Invoice in an ERP
A vendor invoice desktop procedure, in outline: the header states the task runs daily by 15:00, performed by the AP specialist role in the ERP's payables module. Prerequisites: invoice received in the AP inbox, a valid purchase order, vendor active in the master file. Steps: open the payables workbench via the stated menu path; create a new invoice; enter the vendor by number (never by typing the name free-text); enter the invoice number, date, and amount from the document; perform the three-way match of invoice, purchase order, and goods receipt; confirm the match status shows cleared; attach the invoice image; code any non-PO lines to the account list in the appendix; save and submit for approval per the threshold table. Exceptions: quantity or price mismatch beyond tolerance goes to the buyer with a standard email template; a missing goods receipt is parked with a follow-up date; a duplicate-invoice warning is never overridden without written approval from the AP manager. Controls flagged: the three-way match and the approval threshold. Contacts: AP manager for escalations, ERP support for system errors.
That single document is simultaneously training material, a continuity plan, and audit evidence.
Step-by-Step: Rolling Out Desktop Procedures
- List the tasks by desk. For each role, list recurring tasks with frequency and deadline. Prioritize anything only one person knows how to do.
- Write while doing. The fastest method is to perform the task once at half speed, capturing screenshots and noting each action as it happens.
- Use a standard template. Header, purpose, prerequisites, steps, exceptions, controls, contacts — identical structure across every desk.
- Test with a stranger. Have someone who has never done the task follow the document end to end. Every question they ask is a missing step.
- Store them where the work happens. A shared, searchable location with one current version — not personal drives and email attachments.
- Tie reviews to change. Review on a fixed cycle (annually at minimum) and immediately after any system upgrade, and make the procedure update a standing item in every ERP change checklist.
- Use them for cross-training. Rotate coverage using the documents quarterly. Cross-training is both the payoff and the best possible test.
Common Mistakes to Avoid
Writing at policy altitude. A desktop procedure that says review the invoice for accuracy has documented nothing. If it does not name the screen and the field, it is not a desktop procedure.
Letting them go stale. Systems change more often than documents. An unreviewed desk procedure fails precisely when it is needed most — during coverage by someone who cannot tell that step 6 no longer exists.
Real data in screenshots. Vendor bank details and employee records in a widely shared document is a data protection incident in waiting. Mask everything.
One person owns everything. If procedures are written about people rather than by them, they are wrong; if only one person can update them, you have recreated the key-person risk they exist to remove.
No link to controls. In audited environments, a desk procedure that does not flag its control steps forces auditors and process owners to reconcile two documents that inevitably disagree.
How AI Accelerates SOP Creation
WorkProcedures generates desktop procedures and SOPs from a plain-language description of the task — describe how the invoice gets processed and receive a structured, numbered procedure with exception handling built in. Training handbooks bundle a desk's procedures for onboarding, and acknowledgement tracking evidences that the team has read the current versions. The free plan includes 3 SOPs, so you can document your riskiest desk today.
Conclusion
Desktop procedures are the cheapest insurance in back-office operations: a few hours of writing per task in exchange for painless audits, survivable absences, and faster onboarding. Start with the task only one person knows, write it click by click, and keep the review date honest. Visit WorkProcedures to build your desktop procedures today.