A month-end close is a long sequence of small judgements made against a deadline. Transactions get matched, coded, checked against budget, explained in writing, and reconciled before the pack goes out. Most of that work is pattern recognition at volume, which is the category of task a language model handles well once a person is checking the output.

Language models are genuinely useful across several close steps, and unreliable at one of them. Matching suggestions, transaction categorisation, drafting and document extraction all produce a first pass that a reviewer can move through quickly. Arithmetic is the step where a model will hand back a confident wrong number, and a wrong total in a set of accounts costs more than a slow close.

This article covers the close tasks where an LLM earns its place in an Australian finance function, the reconciliation pattern that keeps a person in the approval step, and the guardrails that decide whether the finished pack can be defended. Recomputed totals, client data rules, a record of which tool produced what, and sign-off by a qualified person.

Where an LLM Fits in the Close

The useful split is by task type. Work that is repetitive, text-heavy and easy to verify in a single glance suits a model. Work where a single wrong digit propagates through the accounts suits a formula and a reviewer.

Read down the last column and the pattern is consistent. The model takes on the reading and drafting load, and every decision that changes the accounts stays with a person.

Bank Reconciliation Matching With Human Approval

Bank matching is the highest-volume manual step in most closes, and it is where a model repays the effort first. The reliable design separates the mechanical match from the judgement, then puts the model to work on the part of the problem that is genuinely unstructured: the counterparty references, the abbreviations, the part-payments and the descriptions that no rule anticipates.

The mechanical passes run on amounts and dates, which are exact. Everything that survives those passes goes to a person with a reason code attached, and the model's role is to explain each exception in plain language and to propose what it probably represents.

Month-end bank reconciliation

1. Load the bank statement and the cash ledger into two Excel tables.
   Neither table is edited by hand after loading, and both carry a
   Status column, a Reason code column and a Reviewer column.

2. Build the match key on both sides:
     amount    rounded to the cent
     date      the statement date
     reference uppercased, spaces removed, common suffixes stripped

3. Run three passes in a fixed order:
     pass A  amount and reference match exactly        -> Auto matched
     pass B  amount matches, date within 3 days        -> Suggested
     pass C  reference matches, amount differs         -> Suggested, variance shown
     remainder                                         -> Exception

4. Every Suggested row requires a person to set Approved or Rejected.
   Only Approved rows post to the ledger.

5. Recompute the reconciliation in Excel:
     bank closing balance - unreconciled items = ledger cash balance.
   If the difference does not clear to zero, nothing posts and the
   exception list is worked again.

A workable status formula for the first two passes, written over an Excel table called Ledger:

Match status (Bank[Status])

=IF(COUNTIFS(Ledger[Amount],[@Amount],Ledger[Reference],[@Reference])>0,
    "Auto matched",
    IF(ABS(Ledger[Date]-[@Date])<=3,"Suggested","Exception"))

The important property of that structure is that the approval column is empty until a person fills it. A model that pre-fills Approved, or a macro that treats Suggested as Approved to save time, removes the control that the whole reconciliation depends on. The exception list is the deliverable of the exercise, because it holds the items that need a decision: an unallocated deposit, a bank fee not yet recorded, a customer payment applied to the wrong invoice.

Classifying Uncoded Transactions

Uncoded transactions arrive with a supplier name, a description, an amount and a date. Deciding the account and the GST treatment for each one is repetitive work that a model does well when it is given the chart of accounts as a fixed list and required to choose from it.

Set the constraints before the first run. The model must return a code that already exists in the chart of accounts, with the exact code text, and must return a confidence flag. Rules that carry a tax consequence need a lower tolerance than rules that only affect management reporting. GST treatment is the clearest example: a taxed sale carries GST at 10%, a GST-free supply carries none, and the two produce different BAS positions. A model that guesses the treatment creates a compliance problem that no journal fixes quietly.

Practical rules that keep classification usable:

• Supply the chart of accounts and a short set of coding conventions in the instruction, so the model is choosing from a list a person maintains.
• Require a confidence flag on every line. Rows below the firm's threshold go to a review queue and a person codes them.
• Keep the model's proposal in its own column beside the coded account. Overwriting the account column destroys the evidence of what was proposed and what was changed.
• Do not let a model create a new account, split one transaction into two, or change an amount. Those are accounting decisions.

Payroll is worth separating out, because it is rule-driven work with a defined answer. Super guarantee sits at 12%, modern award leave loading is commonly 17.5%, and the applying classification comes from the award. That work belongs in a calculation, and a model's role is limited to summarising what the payroll system already produced.

Draft Variance Narratives From a Numbers Table

Drafting commentary is the step most finance teams describe as the time sink, and it is where a model produces the most visible benefit. The method is to hand it a table and nothing else, then require every sentence to trace to a row in that table.

The commentary a model should return from that table is short: revenue finished $150,000 above budget for the month, cost of sales rose by $60,000, and gross margin improved from 38.0% to 40.0%. Every figure in those sentences is present in the source table, and each one can be tied back in a few seconds. Revenue at $1,650,000 against a $1,500,000 budget is 10.0% favourable, and the margin moved two percentage points, which is arithmetic a reviewer can confirm without opening the ledger.

What the same table cannot support is a cause. A model asked why revenue was up will supply a plausible reason, and a plausible reason in a board pack reads as fact. Feed it the driver data from the model, or the sales commentary the team already wrote, and let it explain only what it has been given. Where no cause exists in the source, the correct draft says the movement is unexplained and needs follow-up.

Two further rules improve the output. Cap the length, so the draft stays a summary a person will actually edit. And keep foreign currency movements separate, because they follow a standard rather than a story. AASB 121 translates the income statement at the average rate for the period, assets and liabilities at the closing rate, and takes the difference to a translation reserve in equity. The translation is calculated in the worksheet, and a model's contribution is the sentence that explains the movement to a reader.

Extracting Data From PDFs and Supplier Statements

Supplier statements, remittance advices, freight invoices and bank PDFs carry data that someone types into Excel every month. Extraction is the task where a model is at its most capable and where a quiet error is easiest to miss, because the output looks like a clean table.

The pattern that holds up has three parts. The model reads the document and returns structured rows with a page reference for each. The extracted rows land in a staging table that nobody codes from. Then the staging table's total is agreed to the total printed on the source document before any row is used.

Three rules cut most of the risk. Amounts come back verbatim, including a figure that looks wrong, because a model that corrects a supplier's typo has changed the evidence. Nothing is summarised, so a ten-line invoice returns ten lines. And a statement whose extracted total does not agree to its printed total is treated as a failed extraction, which sends it back to a person for a second pass.

Supplier statement reconciliations also deserve a check on the other side. A statement balance that agrees to the creditor ledger is a useful result, and the extraction should let a reviewer reproduce that agreement from the extracted rows alone.

The Close Checklist and the Follow-Up Email

A close is a checklist whether or not anyone writes it down, and the written version is the one a model can help run. Keep the checklist as an Excel table with a step, an owner, a due date, a status column and a link to the evidence, then let the model read it and report.

The model reads the status column and drafts the follow-up email listing the outstanding items, the amounts and dates involved, and the person who needs to act. That draft is genuinely useful, because writing the chase list is a task everyone postpones and nobody enjoys.

Two limits apply. The model reports the status it is given, and it never marks a step complete, because completion is a claim about work that a person has to stand behind. And the email draft carries only facts from the checklist, with the missing invoice described by supplier, amount and period. Where a figure is unknown, the draft asks for that figure.

The same discipline applies to the reporting pack commentary. Hand the model the reconciled tables and the variance drafts, ask for the summary page, then review the result against the numbers. A pack assembled from verified components is quick to check. A pack assembled from a model's memory of earlier conversations is not.

Guardrails: Totals, Client Data and the Audit Trail

The guardrails matter more than the productivity gains, because they decide whether the finished pack survives a review.

Recompute every total. A model is never the source of a total in a deliverable. The figure a model drafted is a comparison point, and the number that goes into the pack comes from SUM, SUMIFS, a pivot or a reconciliation built in cells.

Before the pack is released

1. Every total in the pack is a live formula, pivot or SUMIFS with a visible source range.
2. Each figure a model drafted is compared against that formula.
3. Any difference is investigated and explained, including a difference under a dollar.
4. The comparison is noted on the working paper beside the figure.
5. The reviewer named on the pack can point to the source of every number in it.

The second guardrail is the client data rule, and it is a firm-level decision. Consumer chat tools are unsuitable for unpublished results, client identifying details and anything received under a confidentiality agreement, and a business agreement that excludes training on submitted data is the minimum standard for the rest. The practical framework is set out in Keeping Client Financial Data Safe When Using AI, and a close that depends on a model needs those rules settled before the busy week starts.

The third guardrail is the record. Which tool produced which draft, on which date, and what the reviewer changed. That record is cheap to keep while the close is running and impossible to rebuild afterwards, and it is what makes a number produced with AI assistance defensible to a client, an auditor or a lender two years from now.

The fourth is sign-off. The model drafts, a qualified person reviews and signs, and the accountability sits with the signature. A close where nobody can name the reviewer is a close with no control in it, however good the drafts looked.

Add these four to the workflow and the productivity gain survives scrutiny. A close that runs on model drafts, Excel recalculations, a recorded trail and one named reviewer is faster than last month and no easier to argue with.

Related reading

• Mastering the Month End Close: A Guide for Business Owners
• Using AI in Excel for Business Data Analysis
• Financial Reporting Automation