Journal Entry Maker-Checker Queue

The problem this kills

Manual journal entries are where control quietly breaks down. Someone keys an adjusting entry into the GL, maybe attaches a spreadsheet, maybe emails a manager "can you look at this," and it gets posted. Was it balanced? Did the debits actually equal the credits, or did a fat-fingered line slip through? Were those real account numbers, or a typo into a suspense account? Was the period even open? Did anyone other than the preparer actually look at it - or did the same person who made the entry also approve it?

When the auditor shows up and asks "show me who prepared this entry, who reviewed it, what support they looked at, and prove it's not the same person," the honest answer in a lot of teams is a shrug and a scroll through email. That's a segregation-of-duties finding waiting to happen.

This tool replaces the email-and-trust approach with an enforced maker-checker workflow: the preparer drafts, the system checks the math and the period, a different person reviews the entry and its backup, and only then does it become an approved entry you can export to the GL - with a complete record of who did what, and when.

What you'll build

A small internal web app, just for your accounting team, that:

• Lets a preparer key a journal entry line by line (account, debit, credit, memo) - or import a draft from a CSV / Google Sheet - and attach the backup documents (the invoice, the reconciliation, the calculation) right on the entry.
• Validates automatically before it can go for review: debits must equal credits (balanced), every account must exist in your chart of accounts, and the entry's period must be open (closed-period entries are blocked).
• Routes the entry to a reviewer who is a different person than the preparer - enforced in code, not by honor system.
• Gives the reviewer a clean approve / reject screen with the entry, the running balance, and the attached support, plus a comment box.
• Locks posted/approved entries so they can't be quietly edited after the fact.
• Dedupes on entry reference so the same journal can't be submitted twice.
• Exports approved entries in the exact columns your GL import expects, plus a complete audit log of every action and change.

What's inside the Implementation Plan

The plan is a single markdown file you paste into Claude Code (a free AI coding agent). It walks the agent through building the whole tool, step by step, with a ready-to-paste prompt at the end of every step.

The most important part: the plan opens by interviewing you about your business. Before it writes a single line of code, the agent asks how journal entries get prepared and approved today, what your chart of accounts and entry reference look like, how you define an "open period," your exact balanced and approval rules, your typical and peak entry volumes, and your messiest edge cases (multi-currency, recurring/reversing entries, multi-line allocations, an entry that needs to be unposted). It reads a short tailored spec back to you, you confirm it, and only then does it build - so you get a tool shaped to your close process, not a generic template you have to bend to fit.

Inside you'll find:

• The discovery interview and how the agent turns your answers into the data model.
• The full build: database, login, the JE preparer screen with file attachments, the balance/account/period validations, the reviewer screen, the maker-checker gate, the lock, and the GL export.
• The hard human approval gate and the enforced preparer-is-not-approver rule.
• Verification steps so you can prove it works, and the CSV-export fallback so it's fully usable even before you connect it to your accounting system.

The governance it includes (this is the point)

This isn't a toy. The plan builds in the controls a finance team actually needs:

• Login so only your team can see or touch anything.
• Row-level security so people only see the entries that belong to your organization.
• A complete audit trail - every draft, edit, submission, approval, rejection, and export is logged with who, when, and what changed.
• A hard human-in-the-loop gate - the app validates and drafts, but a real reviewer must approve; nothing reaches the approved export on its own.
• Segregation of duties enforced in code - the preparer of an entry physically cannot be its approver.
• Balanced + valid-account + open-period checks so a broken or mis-dated entry can't move forward.
• Duplicate guards so the same entry reference can't be processed twice, and locked posted entries so approved journals can't be silently changed.

Who it's for

Bookkeepers, staff and senior accountants, controllers, and ops/BPM folks on accounting teams that need real segregation of duties on manual journal entries - without buying a heavyweight close-management platform or waiting on IT. You don't need to write code. You need your chart of accounts, a sample JE, and an afternoon-to-a-weekend.

You've got this - paste the first prompt and let the agent interview you.