A journal entry becomes audit evidence the moment somebody keys it.

The request is for a population, not a sample.

The IAASB issued ISA 240 (Revised) in July 2025, and paragraph 16 makes it effective for audits of financial statements for periods beginning on or after 15 December 2026. The FRC followed with ISA (UK) 240 (Revised March 2026), published on 30 April 2026 and effective from the same date. In the United States the Auditing Standards Board approved SAS No. 151 on 19 August 2026, effective for periods ending on or after 15 December 2028. Three jurisdictions, two dates, and the earlier one arrives for a calendar year company in January.

That timing is the whole point of writing about this now. A standard that governs the year starting in January is not a standard you prepare for during the audit. The entries it reaches are the ones about to be keyed, and several of the things it asks about are properties of the moment of keying rather than properties of the ledger. They cannot be added afterwards.

Most of the commentary has been about the auditor side, and fairly, because that is where most of the change sits. The IAASB fact sheet lists seven areas it strengthened, including a stand back requirement added on top of the one in ISA 330, and it notes that the board removed language in the standard which could potentially undermine the exercise of professional skepticism. One requirement, though, resolves into a request that arrives at your door, and it is worth reading precisely.

Paragraph 49(b) is the one to sit with. The auditor has to obtain audit evidence about the completeness of the population of journal entries and other adjustments made throughout the period. Not a sample, not the year end entries, the population, for the period. A140 explains what is at stake: failing to obtain that evidence may limit the effectiveness of the procedures responding to management override risk. And paragraph 47 removes the escape route, stating that the work in paragraphs 48 to 52 happens irrespective of the auditor’s assessment of the risk of management override.

Five characteristics, and the columns behind them.

Appendix 4 of the standard is the part worth photocopying. It sets out considerations for selecting entries to test, and inside it there is a short list of what the appendix calls the unique identifying characteristics that inappropriate entries often have. Five of them, stated plainly. Read as a checklist they are unremarkable. Read as a column list they are specific, and the arithmetic is uncomfortable: only one of the five is a number.

Four of the five depend on metadata rather than on the figure, and metadata is the part a finance system treats as optional. A description is a nullable text field almost everywhere. A preparer is often whatever identity the integration was configured with. A posting frequency per account is not stored anywhere, because it is a property of the population rather than of the row. And the fourth characteristic, entries with no account number, is really a question about whether part of your population lives outside the ledger altogether.

The appendix does not stop at five. It also points at accounts that have not been reconciled on a timely basis or that carry unreconciled differences, at accounts holding intercompany and related party transactions, at entries made by individuals with administrative or powerful user access, and at accounting estimates calculated in end user computing tools such as spreadsheet software. Each of those is a data question too, and each has a cheap answer if it is asked before the period rather than after it.

Two dates, and the distance between them.

The third characteristic is the one that repays attention, because it is named twice. Appendix 4 lists entries recorded at the end of the period, or as post closing entries, that have little or no explanation or description. A144 then says the same thing more sharply while explaining why paragraph 49(c) exists: among the entries most susceptible to management override are manual adjusting entries and adjustments made directly to the financial statements that occur after the closing of a reporting period and have little or no explanatory support.

Evaluating that needs two dates. The accounting date, which says which period the entry belongs to, is an accounting decision and every system stores it. The timestamp of the write, which says when a person actually keyed it, is a system fact and plenty of systems either do not store it or do not export it. An entry dated 31 January and written on 9 February is a perfectly normal accrual. The same entry written on 9 April, after the close, with an empty description, is the exact shape A144 describes. One column cannot tell those apart.

In our own general ledger the two are separate columns on the entry header, which is a small design decision with a long tail. The accounting date carries the period. The created timestamp carries the moment. The gap between them is computable, which means a review that looks for entries written after the close can be a query rather than an exercise in memory. The same is true of the description: if it is required on a manual entry at the point of saving, the explanatory support A144 asks about exists by default rather than by diligence.

# The journal entry population, as an auditor needs to read it.
# A worked example of structure. No real entry, person or company.

entry:
  id: JE-20270131-000412
  # Two dates, deliberately. The first is an accounting decision, the
  # second is a system fact. ISA 240 (Revised) A144 turns on the gap.
  posting_date: 2027-01-31          # the period this belongs to
  created_at: 2027-02-09T18:41:07Z  # when somebody actually keyed it
  # Nine days after the date it is posted to, and after the close.
  # That combination is what paragraph 49(c) selects on.

  status: POSTED                    # DRAFT | POSTED | VOIDED | REVERSED
  # Only a DRAFT can be changed. A posted entry is corrected by a new
  # linked entry, never edited, so the population stays additive.

  # Origin, classified at write time rather than guessed later.
  # This is the answer to paragraph 35: how entries are initiated.
  source_type: MANUAL              # MANUAL | ACCRUAL | IC_ELIMINATION | ...
  source_id: null                  # the document behind a derived entry

  # Preparer and approver are different columns. One identity column
  # cannot express the segregation failure Appendix 4 describes.
  created_by: USER-118
  approved_by: USER-042
  approval_rule: rule_manual_over_50k_to_controller
  approval_recorded_at: 2027-02-09T19:02:55Z

  # Named twice in the standard as the marker on period end entries.
  # Required on a manual entry, not on a machine generated one.
  description: Accrue Q4 marketing services, invoice not yet received
  support_reference: DOC-2027-00318

  # A correction points at what it corrects, and says why.
  reverses_id: null
  reversed_by_id: null
  source_reason: null

lines:
  - line_number: 1
    account: 6400                  # never blank on a ledger line
    account_postings_this_period: 214   # the seldom used test needs a count
    debit_credit: DEBIT
    amount: 48_000.00
    currency: USD
    functional_amount: 48_000.00
    department: DEPT-MKT           # dimensions carry the related party test
    counterparty_entity: null

  - line_number: 2
    account: 2110
    account_postings_this_period: 6      # six times all period, worth a look
    debit_credit: CREDIT
    amount: 48_000.00
    currency: USD
    functional_amount: 48_000.00

# Completeness, the paragraph 49(b) question, answered by counting.
population_for_period:
  period: 2027-01
  numbering_scheme: JE-YYYYMMDD-NNNNNN   # per entity, per day
  entries: 3_184
  lines: 9_702
  sequence_gaps: []                      # a gap is a question with an answer
  # Adjustments made above the ledger belong in the same count, or they
  # sit outside the population and A140 asks about them anyway.
  adjustments_above_the_ledger: 0

Two details in that shape are worth calling out. The origin of the entry is classified when it is written rather than inferred later, which is what makes paragraph 35, the requirement to understand how entries are initiated and processed, answerable with a group by instead of a narrative. In our ledger that classification is a single field whose permitted set has grown to forty six values as modules were added, from a plain manual entry through accruals, depreciation, revaluation and intercompany elimination, so the question of which entries were manual is a filter rather than a reconstruction.

The other is the numbering. Completeness in 49(b) is much easier to evidence when entry numbers run in a visible sequence within a period, because then a gap is a question with an answer. Ours are day stamped per entity and allocated from a counter inside the same database transaction that writes the entry, which is a dull implementation detail that happens to be the reason a population count can be checked rather than asserted.

What a ledger that ties actually proves.

There is an assumption underneath a lot of audit readiness conversations that is worth testing before spending money on anything. The books tie. Debits equal credits, the trial balance is clean, so the entries behind it are presumably fine. A138 pushes back on the auditor side, noting that automated processes and controls may reduce the risk of inadvertent error but do not overcome the risk that management inappropriately overrides them, and adding that where information is transferred automatically there may be little or no visible evidence of such intervention.

We ran the measurement rather than asserting it. Using the published logic of the trial balance checker on this site, we generated 100,000 books of 250 rows, each tying by construction, and disturbed each one twice: once with a balanced reclassification that moves an amount between two accounts and leaves both sides equal, and once with a one sided change of the same magnitude.

Neither result is a criticism of the tool, and the tool says so itself: its own source notes that a trial balance which ties is a necessary check and not a sufficient one, because it proves the debits and credits are equal rather than that every entry was posted to the right account. That is the distinction the standard is built on. The tie test is complete evidence about arithmetic and no evidence at all about appropriateness, which is why paragraph 48 asks about the appropriateness of entries and 49(b) asks for the population rather than the totals.

The practical reading is not that a monthly tie is pointless. It is that the tie and the population are two different controls answering two different questions, and a finance team that has only the first has none of the second. Building the second is mostly a matter of what each row carries.

Route approvals on the attributes that will be selected on.

Here is the part that turns a compliance reading into an operating one. Appendix 4 tells you what an auditor will select on. Paragraph 36 has the auditor evaluating the design of your controls over journal entries. Those two facts point at the same small set of attributes, which means the approval rules you set for your own reasons can be pointed at the entries most likely to be picked. The entries that get selected then arrive carrying an approval trail, which is a much better conversation than producing one later.

In our own approval engine a journal entry rule is a set of conditions combined with and or or, followed by sequential approval layers naming a person or a role, evaluated first match wins in a defined order. Being precise about what is built today: four condition attributes evaluate against an entry, and they map onto the standard neatly. The amount, which is the fifth Appendix 4 characteristic and the ordinary materiality question. Who created it, which is the second characteristic. Which entity it belongs to, which is how the intercompany and related party point in Appendix 4 usually surfaces in a group. And the origin of the entry, which separates a manual posting from a system generated one, the distinction A99 draws between standard and non standard entries. A fifth condition type exists for matching an arbitrary custom field and does not yet evaluate, so the seldom used account characteristic is a query you run over the period rather than a rule that routes at the moment of posting.

Two other things in our own ledger do work here that is easy to underrate. Only a draft entry can be changed: once an entry is posted, an update is refused, and there is no hard delete of a posted general ledger entry at all, so the archive path is a void that leaves the row in place. A correction is therefore a new entry that points at the one it reverses and records the reason. That keeps the population additive, which matters directly for 49(b), because a population you can only count after reasoning about what was mutated is a population you have to explain rather than one you can state. Period locking does the matching job on dates, refusing a post or an amendment into a period that has been closed.

What to do before the period starts.

• Fix the effective date for your own audit before anything else. ISA 240 (Revised) applies to periods beginning on or after 15 December 2026, so a calendar year company is inside it for the year starting in January. That is the year whose entries will be tested, which is why this is a recording decision now rather than an audit preparation task later.
• Pull one journal entry export for the current period exactly as you would hand it to an auditor, and check which of the five Appendix 4 characteristics you can answer from it without going back to the system. The usual answer is one: the amount.
• Check whether your export carries two dates or one. If the accounting date and the time the entry was written are the same column, the period end characteristic in A144 cannot be evaluated at all, and that is the characteristic the standard singles out.
• Look at who the preparer is on automated postings. If every system generated entry carries one service account and every manual entry carries a real person, the per person count is useful. If manual entries also come through a shared login, it is not.
• Count the blank descriptions on manual entries in the current period. A144 names little or no explanatory support as the marker on exactly the entries paragraph 49(c) requires to be selected, so a blank description is the field that turns an ordinary entry into a selected one.
• Write down where every adjustment between the ledger and the reported statements is made, and by whom. Intercompany eliminations, consolidation reclassifications, and anything keyed into a reporting pack are part of the population under A140 whether or not they ever reached the general ledger.
• Decide how a correction is made and hold the line on it. A reversal that links to the entry it reverses and records why leaves a readable history, and an edit in place leaves nothing. This is also what keeps the population count stable, because a reversal adds rows rather than changing them.
• Check that your entry numbering makes a gap visible. Completeness under 49(b) is far easier to evidence with a per period sequence than with an opaque identifier, because a missing number is a question with an answer.
• Set approval routing on the attributes the standard says will be selected on: the amount, the preparer, the entity, and the origin of the entry. The entries most likely to be picked then arrive with an approval trail already attached.
• Ask your audit team, now rather than in the field, what form they want the population in and what they will do to test its completeness. A140 makes this their requirement, and the extract they need is much cheaper to build before the period than during it.
• If you are a United States filer, note the second date. SAS No. 151 was approved on 19 August 2026 and is effective for periods ending on or after 15 December 2028, with early implementation permitted, so the international and UK dates arrive first and the same data work covers all three.

Where this goes wrong, and how to see it coming.

• Treating a ledger that ties as the readiness test. It is a real control and it proves the arithmetic. It does not speak to appropriateness, which is exactly the distinction A138 draws when it notes that automated processes reduce inadvertent error without overcoming management override. The measurement further down puts a number on it.
• Reading this as a period end exercise. Paragraph 49(b) asks about the population made throughout the period and 49(d) asks the auditor to consider testing entries across the whole year. The period end selection in 49(c) is a floor rather than the scope.
• Assuming the general ledger is the population. A137 names adjustments made directly to the financial statements, and A140 names top side adjustments made directly to reported amounts. For a group, the consolidation layer is usually where the least evidenced entries are.
• Letting one service account own every automated posting and some manual ones. It is a small convenience that removes the second Appendix 4 characteristic entirely, and it is the one most likely to be tested first because it needs no judgement to apply.
• Allowing a blank description on a manual entry. It costs nothing to require and it is named twice in the standard as the marker on the entries most susceptible to override.
• Correcting a posted entry by editing it. A138 warns that where information moves automatically there may be little or no visible evidence of intervention, and an in place edit is the manual version of the same problem. A linked reversal answers the question that an edit erases.
• Building the export to answer a sample request. The request in 49(b) is about the whole population, so an extract that can only return a selection will be asked for again in a different shape.
• Expecting the walkthrough conversation to be enough. Paragraph 68(b) makes the auditor document the sources their understanding came from, which pushes the evidence toward something produced by the system.

Data and API considerations.

• A posting date and a created timestamp are two different facts and both are needed. The first is an accounting decision and belongs to the period. The second is a system fact and belongs to the moment. Storing only the first makes the A144 characteristic unanswerable, and storing only the second makes the period assignment unauditable.
• The origin of an entry is worth classifying at the time it is written, not derived afterwards. Deriving it later means guessing from the description, and a guess is not evidence. A stored origin code turns paragraph 35, which asks how entries are initiated and processed, into a group by rather than a narrative.
• Preparer and approver have to be separate fields to say anything about segregation. Appendix 4 lists the segregation failure explicitly, naming the case where one person has custody of an asset, authorises the transaction and records it. One identity column cannot express that.
• A per period numbering sequence is cheap completeness evidence. If entry numbers run without gaps within a period, a missing number is visible and the population count is checkable. An opaque identifier is fine for a database and weak for 49(b).
• Descriptions should be required where judgement was applied and optional where it was not. A required free text box on a machine generated depreciation run produces filler. A required description on a manual period end adjustment produces the explanatory support A144 is asking about.
• Reversals should add rows, not replace them. A correction expressed as a new entry that points at the one it corrects, with a reason stored, keeps the population additive. That matters for 49(b), because a population you can only count after excluding mutations is a population you have to explain.
• Dimensions matter to the account characteristic. If intercompany and related party activity is identified by a dimension rather than by dedicated accounts, the Appendix 4 point about entries touching intercompany or related party balances has to be answered from the dimension, so it needs to be on the line and populated.
• If a spreadsheet stays in the loop, give it a register. Appendix 4 names accounting estimates calculated in end user computing tools as an opportunity for bias or fraud. A dated, numbered register of those calculations with an owner is a far better answer than a folder.

The evidence to keep as you go.

A146 notes that the auditor may need to obtain and examine supporting documentation to determine the business rationale for an entry, including whether it reflects the substance of the transaction. A147 adds that automated tools and techniques may be used to determine the completeness of the population or to select items, and that how useful they are depends on how you process entries. Both point the same way: the evidence is better when it is a by product of the posting rather than a retrieval exercise.

• For the population as a whole: a per period extract of every entry and line, with the count and the numbering range, so completeness under 49(b) is a statement somebody can check rather than accept.
• For each manual entry: the preparer, the approver, the accounting date, the timestamp it was written, the description, and the supporting document reference. A146 says the auditor may need to examine supporting documentation to determine the business rationale, so the reference is worth storing beside the entry rather than in an inbox.
• For each entry keyed after the close of a period: the explanatory support, attached at the time. This is the single item A144 names, and it is the one that cannot be produced convincingly two years later.
• For each adjustment made above the ledger: what it was, who made it, what it eliminated or reclassified, and where the number came from. If eliminations are ledger entries with an origin code, this is already answered.
• For the controls: the approval rules as they stood during the period, not as they stand today. Paragraph 36 has the auditor evaluating design, and a rule set with no history cannot evidence what was in force in March.
• For the process description: a system produced report of posting activity by origin and by preparer for the period. Paragraph 68(b) makes the auditor document their source, and this is the artefact that makes the source a good one.
• For corrections: the reversal, the entry it reverses, and the reason, linked. A correction history is the cheapest possible answer to a question about whether the population was altered.

Questions worth asking at the next finance meeting.

• Does our journal entry export carry the accounting date and the time the entry was written as separate fields, and if not, what would it take to add the second one before the period starts?
• How many distinct people posted manual entries last period, and could we produce that count without a developer?
• What proportion of our manual entries in the last close carried an empty description, and who is comfortable defending that number?
• Where exactly do our consolidation and intercompany eliminations get made, and are they inside the population we would hand over?
• If an auditor asked us to demonstrate that the journal entry population for the period was complete, what would we show them?
• When somebody corrects a posted entry today, does the original stay visible, and can we see why the correction was made?
• Which of our approval rules are triggered by the preparer rather than only by the amount, and should that change?

An audit request you can answer with a query.

Read as a compliance event, ISA 240 (Revised) is a long standard with a hard date. Read as a data brief, it is five questions about each entry. Which account, and how often is that account used. Who prepared it, and who approved it. What period does it belong to, and when was it actually written. Is there a description. And how round is the amount. Answer those for your own book and the population request becomes an export.

The genuinely good part is that all five are worth having anyway. A preparer distinct from an approver is segregation of duties. A required description on a manual entry is a favour to whoever reads the ledger next year. Two dates rather than one is how you find out that a third of last year’s adjustments were keyed after the close. A stored origin code is how the close gets faster. None of them was invented by a standard setter, and none of them needs an audit to justify it.

If you want a concrete starting point, start with the assumption this article tested. Take a trial balance you trust, tie it, and then ask what that tie proved. The Rivane trial balance checker totals each side, reports the difference to the cent, and flags rows carrying an amount on both sides or a negative figure, which is the same engine the 100,000 trial measurement above came from. It runs in the browser and it is free to use. Run it, get the clean result, and then go and look at what your journal entry export carries.

Sources

• International Standard on Auditing (ISA) 240 (Revised), The Auditor’s Responsibilities Relating to Fraud in an Audit of Financial Statements, IAASB final pronouncement, July 2025. The PDF was downloaded and read rather than summarised by a fetch, and every paragraph number quoted here comes from that text. Source for the effective date in paragraph 16, for the understanding of how journal entries are initiated, processed, recorded and corrected in paragraph 35, for the controls over journal entries in paragraph 36, for the requirement in paragraph 47 that the journal entry work is performed irrespective of the assessed risk of management override, for the four limbs of paragraph 49 including the completeness of the population in 49(b), for the documentation requirement in paragraph 68(b), for the observations on automated posting and invisible intervention in A138, on top side adjustments in A140, on the integrity of the population in A141, on period end and post closing entries with little explanatory support in A144, and on automated tools and techniques in A147, and for the five characteristics of an inappropriate entry set out in Appendix 4.
• IAASB fact sheet, The Auditor’s Responsibilities Relating to Fraud in an Audit of Financial Statements, July 2025. Downloaded and read. Source for the seven areas the board says it strengthened, for the stand back requirement added on top of the one in ISA 330, for the statement that the board removed language which could potentially undermine the exercise of professional skepticism, for the confirmation that the standard applies to entities of every size, type and complexity, and for the enhanced key audit matter reporting that applies to listed entities.
• Financial Reporting Council, FRC Publishes Final Revisions to UK Auditing Standards on Fraud and Going Concern, published 30 April 2026. Source for the UK position: ISA (UK) 240 (Revised March 2026) and ISA (UK) 570 (Revised March 2026), effective for audits of financial statements for periods beginning on or after 15 December 2026, the same date as the international standard.
• AICPA, New Auditing Standard Clarifies and Enhances CPAs’ Responsibilities Relating to Fraud in a Financial Statement Audit. Source for the United States position: the Auditing Standards Board approved SAS No. 151, The Auditor’s Responsibilities Relating to Fraud in an Audit of Financial Statements, on 19 August 2026, superseding SAS No. 122 section 240, effective for audits of financial statements for periods ending on or after 15 December 2028 with earlier implementation permitted.
• PCAOB staff publication, Audit Focus: Journal Entries, January 2025. Used for the United States framing of the same completeness point, including the expectation that the auditor tests the accuracy and completeness of the journal entry population produced by the company, and the reminder that the sources include manual and automated entries from subsidiary ledgers and other systems as well as post closing or top side entries not yet reflected in the general ledger.
• Journal of Accountancy, ASB approves standard on auditors’ responsibilities relating to fraud, August 2026. Used as a second independent read of the SAS No. 151 approval date and effective date.
• Rivane trial balance checker. The tool referred to in this article, published on this site. The 100,000 trial measurement quoted here was produced by running its own published logic, which totals each side, reports the difference, and flags rows carrying an amount on both sides or a negative figure.

A note on how this was researched. Every statement about what ISA 240 (Revised) requires comes from the approved IAASB pronouncement, downloaded as a PDF and read rather than summarised by a fetch, and the paragraph numbers quoted here are the ones in that document. That distinction has burned us before on standard setter PDFs, where a machine summary produced a confident and wrong account of a different standard, so the rule now is to read the text. The effective dates for the United Kingdom and the United States come from the FRC and AICPA announcements respectively, with the SAS No. 151 dates confirmed against a second independent report. The PCAOB staff publication is cited only for the United States framing of the completeness point and not for any international requirement. No suitable public posts on X were found on this topic during research, so none are embedded, and nothing has been invented in their place. The measurement is reproducible: 100,000 generated books of 250 rows, each tying by construction, disturbed once with a balanced reclassification and once with a one sided change of the same magnitude, run through the published logic of the trial balance checker on this site. The generated books are synthetic and are described as such. The export shape and every identifier in it are a worked example of structure and describe no real entry, person or company. Statements about Rivane describe what is built and shipped today, including the point that one approval condition type does not yet evaluate. Rivane has no public customers to cite and none are implied. Nothing here is audit, accounting or legal advice, and your own auditor decides what they need from you.