How to Use Claude to Draft AP Workflow Documentation for Your Team

Here's a problem that hits growing finance teams at a very specific moment.

Your AP process works, but it only exists in people's heads. One person knows how invoices get coded. Another knows the approval thresholds. A third knows what happens when a vendor's payment details change. It's functional, but it's undocumented. And then something forces the issue: a new hire who needs training, an auditor who asks for your procedures, a key person leaving, or simply the realisation that a process nobody has written down isn't really a process, it's a set of habits.

Writing it all up is the task everyone agrees is important, and nobody wants to do. It's tedious, it's detailed, and staring at a blank page, trying to remember every step and exception, is genuinely hard.

Claude removes most of that pain. It can take what you know about your AP process, even in rough, spoken-out-loud form, and turn it into clean, structured, professional documentation. SOPs, process maps, approval matrices, exception-handling guides, the lot.

This post is part of the Claude for AP Teams series. It's for finance leaders building AP documentation from scratch, whether you're standing up a new team, scaling a function that outgrew its informal habits, or getting ready for an audit that needs your procedures on paper.

We'll cover how to get the process out of your head and into Claude, the prompts to build each type of documentation, and how to keep it all consistent and maintainable.

Why AP Documentation Matters More Than It Seems

Before the how, a quick word on why this is worth doing properly, because good documentation does more than tick a box.

It survives people leaving. When your AP process lives only in one person's head, that person's leaving is a crisis. Documented, it's a handover.

It makes training fast. A new AP hire with clear documentation is productive in days, not weeks. Without it, they learn by asking, interrupting, and making mistakes.

It's what auditors want. Documented, consistently followed procedures are the foundation of a clean audit. "This is how we do it" isn't good enough. "This is our documented procedure, and here's the evidence that we follow it."

It exposes the gaps. The act of documenting a process forces you to confront the parts that don't actually work, the undefined exception, the approval nobody owns, the step that depends on one person remembering. Writing it down is often how you discover what needs fixing.

That last point matters. Documentation isn't just a record of your process. It's a diagnostic of it.

What Claude Can and Can't Do Here

What Claude does well:

• Turns rough, unstructured descriptions of your process into clean, structured documentation
• Organises steps into a logical sequence with clear formatting
• Drafts SOPs, process narratives, approval matrices, and exception guides
• Ask the right clarifying questions to fill gaps in what you've told it
• Maintains a consistent tone and structure across multiple documents
• Adapts the same content for different audiences, a training guide vs an audit document

What Claude can't do

• Know your actual process, you have to tell it (it can't observe how your team works)
• Verify that what you describe is what actually happens
• Make policy decisions for you (it can suggest, but the thresholds and rules are yours)
• Replace the judgment of someone who knows the process deeply

The honest framing

Claude is a superb drafting partner. It takes the hardest part, turning messy knowledge into clean structure, and does it in minutes. But the knowledge has to come from you. Claude organises and articulates; it doesn't invent your process.

Step 1: Get the Process Out of Your Head

The biggest barrier to documentation is the blank page. So don't start with structure; start with a brain dump, and let Claude impose the structure.

Open Claude and just describe your process, however roughly. You can even dictate it. Don't worry about order or completeness. Then use this prompt.

I'm documenting our accounts payable process. I'm going to describe it to you in rough, unstructured form, just how it works, as it comes to me. It won't be in order, and it won't be complete.

Your job: read it, organise it into a logical sequence of stages, and then tell me what's MISSING, the gaps, the steps I didn't mention, the exceptions I skipped over, by asking me specific questions.

Don't write the documentation yet. Just organise what I give you and identify what you still need to know.

Here's the process:

[DESCRIBE YOUR AP PROCESS HERE, however roughly. How invoices arrive, who handles them, how they get coded, how approval works, how payments get made, what happens with exceptions. Just talk it through.]

Why this is the unlock

This is the unlock. Claude takes your messy description, arranges it into a coherent sequence, and, crucially, tells you what you left out. The questions it asks are the gaps in your documentation. Answer them, and you've done the hard thinking without staring at a blank page.

Step 2: Build the Core SOP

With the process organised and the gaps filled, build the main standard operating procedure, the master document everything else references.

Now build a complete Standard Operating Procedure (SOP) for our AP process based on everything we've discussed.

Structure it as:

1. PURPOSE AND SCOPE
   What this SOP covers and who it applies to.

2. ROLES AND RESPONSIBILITIES
   Who does what in the AP process.

3. PROCESS STAGES
   Each stage of the AP process in sequence, from invoice receipt to payment. For each stage:
   - What happens
   - Who is responsible
   - What system or tool is used
   - What the output is
   - What triggers the next stage

4. APPROVAL REQUIREMENTS
   Reference the approval matrix (we'll build this separately).

5. EXCEPTION HANDLING
   Reference the exception guide (we'll build this separately).

6. CONTROLS AND COMPLIANCE
   The key controls in the process and why they exist.

Write it in clear, professional language. Number every step so it can be referenced. Use plain English. Someone new to the team should be able to follow it.

Format it as a clean document ready to share.

Read it critically

Claude produces a structured, numbered SOP. Read it critically; this is where you catch anything that sounds right in theory but isn't how your team actually works. Correct it, and you have your master document.

Step 3: Build the Approval Matrix

The approval matrix is the single most-referenced piece of AP documentation, and the one most likely to be fuzzy in practice. Make it explicit.

Build an AP approval matrix based on our thresholds.

[STATE YOUR THRESHOLDS: e.g. under $2,500 = manager approval; $2,500-$25,000 = manager + department head; above $25,000 = CFO. Include any special rules, new vendors, capital expenditure, recurring contracts, etc.]

Present the matrix showing, for each spend tier:
- The dollar threshold
- Who must approve
- Whether it's sequential or parallel approval
- The target turnaround time (SLA)
- Any special conditions

Below the matrix, write clear notes covering:
- What happens if an approver is unavailable (delegation rules)
- What happens if an approval SLA is missed (escalation)
- Any spend types that follow a different path entirely

Format it so it can stand alone as a quick-reference document that anyone can check in seconds.

Why the delegation notes matter

The matrix is the document people will actually pin to their wall or bookmark. Keep it clean and scannable. The delegation and escalation notes are where most approval matrices fall short; make sure yours answers "what happens when the approver is on leave," because that's the question that comes up constantly.

Step 4: Build the Exception-Handling Guide

Exceptions are where AP documentation usually goes silent, and where a new hire is most lost. This guide covers the "what do I do when it's not straightforward" cases.

Build an AP exception-handling guide covering the common exceptions our team encounters.

For each of these exception types, document: what it is, how to identify it, the step-by-step resolution process, who to involve, and when to escalate:

1. Invoice with no matching PO
2. Price discrepancy between invoice and PO or contract
3. Quantity mismatch / partial delivery
4. Duplicate invoice
5. Missing or incomplete invoice information
6. Vendor payment detail change request
7. Invoice received after payment was already made
8. Vendor dispute over payment status

[Add or remove exceptions to match what your team actually deals with.]

For each, write it so a team member who has never seen that exception before can follow the steps and resolve it, or know exactly who to escalate to.

Flag the vendor payment detail change process as HIGH RISK and make the verification steps explicit; this is a common fraud vector.

Make the fraud check explicit

The exception guide is the document that makes a new hire genuinely self-sufficient. And the note on vendor payment detail changes is deliberate; that's the one exception where a documented, mandatory verification step (call the vendor on a known number, never act on the email alone) prevents real fraud. Make it explicit in the documentation.

Step 5: Create a Process Map

A visual process map complements the written SOP, some people follow a diagram better than prose. Claude can't draw it, but it can build the structure for you to drop into any diagramming tool.

Create a process map for our AP workflow that I can build in a diagramming tool.

Lay it out as a step-by-step flow, showing:
- Each process step as a box
- Decision points as branches (e.g. "PO match? Yes / No")
- Who owns each step
- Where exceptions branch off and where they rejoin
- The start point (invoice received) and end point (payment made and recorded)

Present it as a structured outline I can follow to build the diagram, use indentation and arrows (→) to show the flow and branches clearly.

Also note which steps are manual and which are automated in our current process, so the map shows where the human touchpoints are.

A map of your process is a map of its slow spots

The output is a blueprint you can build in any flowcharting tool. The note on manual vs automated steps is worth adding, a process map that highlights the manual touchpoints is also a map of where your process is slowest and most error-prone. That's useful beyond documentation.

Step 6: Adapt for Different Audiences

The same process documentation serves different readers differently. A new hire needs a training guide. An auditor needs a controls document. Leadership needs a summary. Rather than writing three documents, have Claude adapt the one.

Using the SOP we've built, create three versions for different audiences:

1. NEW HIRE TRAINING GUIDE
   The process is explained for someone learning it for the first time. More context, more "why," a friendly tone, and a suggested order to learn things in.

2. AUDIT / CONTROLS DOCUMENT
   The same process, but framed around the controls: what each control is, what risk it mitigates, how compliance is evidenced. Formal tone.

3. ONE-PAGE LEADERSHIP SUMMARY
   The AP process at a glance for the CFO or leadership, the stages, the key controls, the approval structure, on a single page.

Keep the underlying process identical across all three, only the framing, depth, and tone should change.

Where Claude saves the most time

This is where Claude saves the most time. Writing three versions of the same documentation manually is hours of work. Claude does it in one pass, keeping the underlying process consistent so the three documents never contradict each other, which is exactly the problem that plagues manually maintained documentation.

Keeping It Consistent and Maintainable

Documentation that isn't maintained becomes wrong, and wrong documentation is worse than none. A few practices to keep it alive:

Version and date every document. Have Claude add a version number and "last updated" date to each. When the process changes, you update the doc and bump the version.

Keep the SOP as the single source of truth. The approval matrix, exception guide, and audience versions all derive from it. When the process changes, update the SOP first, then regenerate the derivatives with Claude, this keeps everything consistent.

Review on a schedule. Set a calendar reminder to review the documentation quarterly. Paste the current version into Claude and ask: "What in this documentation is likely to have drifted from actual practice? What questions should I ask my team to check it's still accurate?"

Document changes as they happen. When the process changes, a new threshold, a new system, a new step, update the documentation the same week, while it's fresh, not at the next annual review.

Where Documentation Ends, and Governance Begins

Here's the honest limit of this entire exercise, and it's an important one.

Documentation describes how your process is supposed to work. It doesn't ensure that it actually does.

You can write the most beautiful AP SOP in existence. It doesn't approve a single invoice. It doesn't enforce the approval matrix; a rushed manager can still approve above their threshold. It doesn't catch the exception that gets handled incorrectly. It doesn't produce the evidence that the documented control was actually applied to invoice #4471 on the third of the month. Documentation is a description of intent. It relies entirely on people following it, consistently, every time, which, as anyone who has run an AP team knows, is exactly the thing that breaks down under pressure.

This is the gap between the documented process and the enforced process. And it's precisely the gap an agentic Intake-to-Pay platform closes. Where documentation says "invoices above $25,000 require CFO approval," Blackbee AI's approval orchestration actually enforces it, routing the invoice to the CFO automatically, every time, and refusing to advance it otherwise. Where documentation says "verify vendor payment detail changes," the platform builds that verification into the workflow so it can't be skipped. And where an auditor asks for evidence that the documented control was applied, the platform's audit trail shows exactly what happened to every invoice, who approved it, against what policy, with what reasoning, automatically, without anyone maintaining a separate log.

Documentation is genuinely valuable, and this workflow will produce excellent documentation fast. But the strongest version of process control isn't a document that describes what should happen. It's a system that makes it happen and proves it did. If your team is documenting AP processes partly because an audit is looming or because the manual process has become too complex to trust to memory, that's often the signal that you've outgrown documentation alone and need enforcement. See how Blackbee AI turns AP policy into a governed, auditable workflow.