Prompt: prepare the year-end audit request list and an explanation file for journal entries flagged by a script

In two sentences

Auditors test journal entries every year, and the questions arrive at the worst moment: in the middle of fieldwork, about an entry nobody remembers. This prompt and a short script let the finance team run the obvious tests first, collect the explanations in advance and hand over a tidy request list with a log of how every file was extracted.

Why do this on the company side

Under the auditing standards in force in Spain (NIA-ES 240, listed on the ICAC page we cite) and internationally (ISA 240), the auditor has to respond to the risk that management overrides controls, and testing the appropriateness of journal entries is one of the procedures. In practice that means the auditor will select entries with unusual features and ask for support. The IAASB has issued a revised ISA 240 that applies to audits of periods beginning on or after 15 December 2026; how and when it is adopted in Spain is for the ICAC to decide, so check the page before your next audit.

None of this tells the company what to do, but the logic is simple: if you know which entries will look unusual, you can gather the support while the people involved still remember them. The tests in this entry are deliberately basic and are not the auditor’s tests. Your auditor may use other criteria, and that is their decision.

The fictitious data

A distribution company, calendar year 2025. The journal has 1,017 entries and 2,034 lines, all balanced. Four users post most of them: an automatic system user for sales imports, two accounts payable clerks and the controller; a temp_user appears twice. Each line has the entry number, the accounting date, the entry date (when it was keyed in), user, source (sales_import, ap_import or manual), account, description, debit and credit. We planted 16 cases of the kind auditors usually ask about.

• Fictitious journal 2025 (CSV)
• Journal-entry test script (Python, standard library only)

Run python3 je_tests.py journal-2025.csv. The approval limit (10,000) and the close date (20 January 2026) are at the top of the script, together with the 2025 national holidays in Spain. Change them to yours, and add your regional and local holidays.

The six tests

The core of the script is a few lines per test:

if manual and 0.95 * THRESHOLD <= a < THRESHOLD: flags["just below approval limit"].append(k)
if manual and (entered.weekday() >= 5 or entered in HOLIDAYS): flags["posted on weekend/holiday"].append(k)
if acc_date <= YEAR_END and entered > CLOSE_DATE: flags["posted after close into the year"].append(k)
if manual and a >= 5000 and a % 1000 == 0: flags["round amount"].append(k)
if by_user[h["user"]] <= 3: flags["user with <= 3 entries"].append(k)

In a spreadsheet with one row per entry, the same tests are columns: =AND(E2="manual",H2>=0.95*$L$1,H2<$L$1), =WEEKDAY(C2,2)>5 (plus a lookup in a holiday list), =AND(B2<=DATE(2025,12,31),C2>DATE(2026,1,20)) and =AND(E2="manual",H2>=5000,MOD(H2,1000)=0), where B is the accounting date, C the entry date, E the source, H the amount and L1 the approval limit.

What the script returns

Six of the seven entries below the limit are consulting invoices from the same supplier, between 9,802.83 and 9,967.69, all keyed in manually by the same clerk. The seventh, JE00498, is an ordinary entry that falls in the band by chance: a reminder that a flag is a question, not a finding. JE01016 is an 18,000 debit to revenue dated 31 December 2025 and keyed in on 12 February 2026. JE01017 is a 25,000 “Adjustment” by temp_user, flagged twice. The duplicate pairs share supplier, amount and invoice number, with a “-1” suffix on the manually entered copy.

The script also prints a first-digit (Benford) comparison for supplier invoices: 632 amounts, mean absolute deviation 0.0069. Use it only as a screening view and compare it with previous years; on a few hundred amounts and with a population of mixed invoice types, it says little on its own.

The extraction log

Auditors and reviewers need to know that a file is complete. Keep one row per file, filled in at the moment of extraction (the first row matches the sample journal; the second is illustrative):

File            | System and report          | Parameters                       | By / when           | Rows  | Control total      | Ties to                      | Difference
journal-2025    | ERP > G/L entries export   | Company 01, 01/01/25-31/12/25    | M. López 15/01/26   | 2,034 | Debits 3,137,503.97| Sum of TB movements 2025     | 0.00
                |                            | all sources, incl. closing       | 10:42               |       |                    |                              |
ap-open-items   | ERP > Vendor ledger        | Open at 31/12/25                 | M. López 15/01/26   | 214   | 318,544.20         | TB account 400 at 31/12/25   | 0.00

The “ties to” column is the important one: a file without a tie-out to the trial balance can be incomplete without anyone noticing, and every test run on it inherits the gap.

How to use the prompt

1. Run the script and keep the full output, with the details of each flagged entry (date, user, account, description, amount).
2. Paste the output as TEST_RESULTS and the log as EXTRACTION_LOG. If the auditor has already sent a request list, paste it as AUDITOR_REQUEST.
3. Read task 1 against the auditor’s list; delete SUGGESTED items you do not need.
4. Send each row of task 2 to the person who made the entry, and replace the blanks with what they answer and the document they provide.

A row of the explanation file should look like this (our own example, not model output):

Variants by ERP: the fields you need

The tests need the user and both dates. Check that your export has them before relying on any result:

• Microsoft Dynamics 365 Business Central: general ledger entries include posting date, document date, user ID and source code; the entry date can be checked through the G/L register.
• Odoo: journal items can be exported with the accounting date, the journal and the “created by” and “created on” fields, which give the user and the entry date.
• SAP: document headers hold the posting date, the entry date, the user and the document type; ask whoever administers the system for a report over them.
• Sage, A3 and Holded: check whether the journal export includes user and entry date. If not, ask your provider how to obtain the audit trail, and record in the log that the user test could not be run.

Spanish companies on a full PGC usually also need the closing and opening entries in the file; decide whether to include them in the tests and write that decision in the parameters column.

Human review steps

1. Tie the journal to the trial balance before running anything, and record the result in the log.
2. Review the parameters of the script (limit, close date, holidays) with whoever owns the approval policy.
3. Read every flagged entry yourself; the assistant only drafts the questions.
4. Get explanations and documents from the people who made the entries, not from the assistant.
5. Agree with the auditor what you will hand over and in what format; their list prevails over the suggested one.

Common mistakes

• Running the tests on an incomplete file. Without the tie-out, no flag (or lack of flags) means anything.
• Using the wrong date. The accounting date tells you which period an entry belongs to; the entry date tells you when it was keyed in. The “after the close” and weekend tests need the second one.
• Treating a flag as a finding. JE00498 is a normal invoice. Write the explanation and move on.
• Letting the assistant write the explanation. It does not know why an entry was made. The prompt forbids it from filling in reasons; check that it obeyed.
• Sharing the full journal with a consumer AI account. Use the business plan your company has approved, or give the assistant only the script’s output.
• Copying test thresholds from the internet. Benford thresholds, round amounts and bands depend on the population; set yours and document why.

Limits

This is preparation, not an audit. The tests are basic, the thresholds are ours and the auditor decides their own procedures and samples. The prompt helps you be organised and answer quickly; it does not reduce the auditor’s work or change their responsibility.