Invoice Intake & GL Coding Assistant
Build an internal tool that reads supplier invoices, drafts the GL account, cost center, and tax coding from your own rules and history, matches to the PO, and waits for an AP clerk to verify every line before anything is accepted.
Upload or paste a supplier invoice, get its header and line items extracted with suggested GL / cost-center / tax coding drawn from your rules and past invoices, verify and adjust each line against the source document, accept it, and export a clean CSV in your AP-import format with the original file linked for audit.
Before you start
- A free Supabase account
- A free Vercel account
- A free Resend account (for notifications)
- Your chart of accounts + cost-center list (a spreadsheet is fine)
- A handful of recent supplier invoices to test with (PDF or pasted text)
The problem this kills
Your AP clerks open a supplier invoice, squint at the PDF, and key the header and lines into your accounting system by hand. Then comes the part that goes wrong: coding it. Which GL account? Which cost center? Is the tax right? They code it from memory, from a sticky note, or from "how we did it last time" - and last time was a guess too.
The result is miscoding that nobody catches until month-end, a reclassification scramble, and the same vendor coded three different ways. Multiply that by hundreds of invoices and you have rework, late close, and a finance team that doesn't trust its own numbers.
This tool ends the guesswork. It reads the invoice, drafts the coding from your rules and your history, shows it to a person, and only saves it once that person has checked every line against the real document.
What you'll build
A private, login-protected web app for your AP team that:
- Takes a supplier invoice as a PDF upload or pasted text.
- Extracts the header (supplier, invoice number, date, currency, totals) and the line items.
- Suggests coding for each line - GL account, cost center, and tax - using your coding rules and what your team coded on similar invoices before.
- Matches to a PO when there's a PO number, and flags mismatches.
- Validates the math - lines plus tax should equal the invoice total - and flags low-confidence extractions so the clerk knows exactly where to look.
- Puts a clerk in front of every line to verify and adjust against the source document before anything is accepted.
- On accept, saves the coded invoice (which then improves future suggestions) and lets you export a CSV in your AP-import format, with the original file linked for audit.
What's inside the Implementation Plan
The plan is a complete, paste-and-go runbook for an AI coding agent (Claude Code). You don't write code - you paste, answer questions, and approve.
It opens by interviewing you about your business - your current invoice process and who does it, the accounting system you import into, the exact shape of your chart of accounts and cost centers, your SKU / category / supplier naming, your coding rules, your typical and peak invoice volumes, and your messy edge cases. It reflects a short tailored spec back to you for a thumbs-up before it builds anything, so the tool fits how you actually work - not a generic template.
From there it walks you step by step: database and security, login, upload and extraction, the rules-and-history coding engine, the PO match, the line-by-line verification screen with the human approval gate, the accept-and-save flow, and the CSV export. Every step ends with a ready-to-copy prompt.
The governance it includes (this is the point)
This isn't a toy. The plan bakes in the controls finance actually needs:
- Login so only your team can use the tool.
- Row-level security so a user only ever sees their own organization's invoices.
- A complete audit trail - who extracted, who changed a code, who accepted, and when.
- A hard human-in-the-loop approval gate: the AI only ever drafts. Nothing is accepted into AP until a clerk has verified the data and the coding line by line against the source document.
- Duplicate guards: the same invoice can't be processed twice - supplier + invoice number + invoice date is the dedupe key, and duplicates are rejected on ingest.
- The original file stays linked to the coded record, so every accepted invoice can be traced back to its source.
Who it's for
AP clerks and AP leads who key invoices and code them by memory, and the controllers who keep cleaning up the miscoding afterward. If your team codes invoices from "what we usually do" and pays for it at close, this is for you. You do not need to be a developer - if you can paste text and answer questions about your own process, you can build this.
You've got this - paste the first prompt and let the agent interview you.