Module 1 · Start safely
Segregation of duties and approval
In short
AI may prepare draft entries and payment lists, but never posts or pays on its own. The people who prepare, approve and execute stay separate, and every approval is recorded by name.
After this lesson you can
- Explain segregation of duties in finance and where AI stands within it
- Set the rule that AI never posts an entry or runs a payment without review and approval by a named person
- Build an approval trail for draft journal entries and payments prepared with AI help
Terms in this lesson
Understand
Segregation of duties is one of the oldest controls in finance. The idea is simple: one person does not hold the whole flow of a transaction. The person who records a vendor bill is not the person who approves its payment, and the approver is not the person who executes the transfer. Whoever reconciles the bank statement should not be the person who holds bank access. That way a single mistake or a single bad intention has to pass more than one pair of eyes before money leaves.
In a small organisation, full segregation is often impossible because there are few people. But the principle can still be kept: the owner or manager approves payments prepared by staff, or someone outside finance reviews the reconciliation each month.
So where does AI stand? AI is a preparer, never an approver or an executor. AI may draft adjusting entries from your notes, group bills by due date, or write explanations of differences. But AI has no name, cannot be held accountable, and can be wrong with no warning sign. Putting AI in the approver's seat is the same as removing one pair of eyes from a flow designed precisely to have several.
From that comes a firm rule for this track: AI never posts a journal entry or runs a payment without review and approval by a person whose name is recorded. The rule holds whatever the tool, including features in accounting systems that offer "create entries automatically" or "schedule payments". What is allowed is AI producing a draft that goes into a queue; posting or paying is done by the person who opens that draft, compares it with the source documents, and approves it.
There are three temptations to recognise. First, volume: with hundreds of small transactions, approving one by one feels slow. The answer is not to remove approval but to approve in batches with a list that can be checked. Second, similarity: this month's transactions resemble last month's, so repeating them automatically feels safe. Yet payment fraud often disguises itself as a routine bill with the destination account changed. Third, trust in the tool: AI output that is usually right makes people stop reading. A wider explanation of when something must not be automated is in the when not to automate lesson.
This is what human in the loop means in finance. An approval that is not recorded is the same as none. For each draft entry or payment prepared with AI help, keep a simple audit trail: who prepared it, that it was AI-assisted, which source documents were matched, who approved it and when. This trail helps at audit time, when a difference appears next month, and when a newcomer asks why an entry was made. The principle of people deciding is explained more generally in the people decide lesson.
Before
The prompt
Make the month-end adjusting entries for depreciation and prepaid expenses, then enter them straight into the system.
What came back
Example of bad output; figures and references invented by the model, do not use: Entries created: Depreciation expense Rp 4,250,000 / Accumulated depreciation Rp 4,250,000 Rent expense Rp 6,000,000 / Prepaid rent Rp 6,000,000 Please post.
After
The prompt
Goal: I need draft month-end adjusting entries for me to review, not to post directly. Reader: my manager, who will approve before posting. Material: I will supply the values myself: monthly depreciation from the asset register ‹depreciation-value›, prepaid rent ‹rent-value› for ‹months› months. Limits: do not compute or invent values; use only the values I give. Shape: a table of debit account, credit account, amount, source document, and an empty column for the approver's name. Check: write for each line which document the approver must match.
What came back
Line 1: Debit Depreciation expense / Credit Accumulated depreciation / ‹depreciation-value› / This month's fixed asset register / Approver: ... Line 2: Debit Rent expense / Credit Prepaid rent / ‹rent-value› divided by ‹months› / Lease contract and payment proof / Approver: ... To match: line 1 with the asset register; line 2 with the lease and amortisation schedule.
What changed
- The first version invents values and asks for direct posting, skipping the approver.
- The second makes AI a draft preparer: values come from you, source documents are named, an approver column is provided.
- The approval trail forms directly from the table's shape.
Common mistake
- Mistake
- Letting an automatic flow pay a routine vendor bill because "it is the same every month".
- Why it hurts
- Routine bills are a favourite disguise for payment fraud: the destination account is changed through an official-looking e-mail. Without a person checking, money goes to the wrong account and is hard to recover.
- Do this instead
- Every payment, routine ones included, is approved by a named person. A change to a vendor's account is always confirmed through a contact already on file, not the contact in the e-mail asking for the change.
Try
Sorting card
Sort: may AI do this as a preparer, or must a person?
Writing explanations of reconciliation differences for review
Drafting adjusting entries from values you supply
Grouping bills by due date
Posting entries to the general ledger
Changing a vendor's destination account in master data
Approving this week's payment list
6 cards left
Your accounting system offers a new feature: AI reads incoming invoices, then creates and posts entries itself. What is the right stance?
Take home
Approval trail for AI-assisted drafts
- Who prepared it, and whether AI assisted.
- The source documents matched for each line.
- The approver's name, separate from the preparer.
- The approval date and the posting or payment date.
- A note when the approver changed any value.
- No feature posts or pays without an approval step.
What went wrong for us
AI never posts or pays on its own
- Context
- The apps we build have parts that touch money: balances, bills and usage credits. Technically it would be very easy to let a model or agent change a balance or trigger a payment directly.
- What tends to go wrong
- This is a rule we keep. No model or agent can post a balance change or run a payment. At most it prepares a proposal; the proposal runs only after a person has reviewed and approved it, and the approval is recorded.
- What it costs if ignored
- Money that leaves because of a misreading or a hidden instruction is hard to recover. With no approving person, no one can explain why the transaction happened.
- Root cause
- Full automation feels efficient for repeating transactions, and the line between preparing and deciding is easily lost when a tool acts directly.
- How we do it
- Actions that move money are not registered as tools a model can call. Proposals wait for a person with the right permission to confirm them.
- The rule we keep
- Every feature that touches money is designed around one question: who approves, and where is their name recorded?
The lessonAI prepares; a named person approves and posts.
What it means for your workIf your accounting system offers automatic entries or payments, use them only as drafts awaiting a person's approval.
