Entries posted on a Sunday, on Diwali or at 2 a.m. are among the first filters in any journal entry test. Used carelessly they produce hundreds of false hits in an Indian company, where Saturdays may be working days, month-end closes run through holidays and accounts teams sit in different time zones. Used carefully they point to a small set of entries worth a conversation.
Last reviewed: 17 October 2026. Facts checked. We did not open the ICAI text of SA 240 or any regulator guidance on posting-time tests; none is claimed to require this test, which is a common analytic choice rather than a stated procedure. We did not open any official holiday list; the client's own calendar is the source to use. The example is invented.
Why timing is a signal at all
Most routine postings follow office rhythm: invoices on working days, payroll around the same date each month, payments in banking hours. Entries that break the rhythm are not necessarily wrong, but a person making a questionable adjustment may avoid the days when colleagues are present to see it. Timing is also a cheap test to run once the data carries the right fields.
This is one indicator among several used in journal entry testing, and it works best when combined with others, not on its own.
The fields you need
Two dates matter and they are often confused.
- Posting date (document date): the accounting date the entry belongs to. In Tally it is the voucher date and can be set to anything.
- Entry date (creation or system date): when someone actually keyed it. In SAP-type systems this sits in the document header along with the user and often a time stamp.
A weekend test on the posting date mostly catches the accountant who dates a voucher 31 March, which falls on a Sunday in some years. That is harmless. The meaningful test runs on the entry date and time: when was the entry really made, and by whom?
If the data holds only voucher dates, say so in the working paper. In Tally the edit log, if enabled, may carry creation and alteration times; see our guide to the Tally audit trail. If neither is available, a timing test is not possible on that data and the auditor should not pretend otherwise.
Build the client's real calendar first
A weekend test that assumes Saturday and Sunday are off is wrong for many Indian clients. Ask for:
- The working-week pattern by site: five days, six days or a rotating week for factories and hospitals.
- The holiday list published for the year, including state-specific and festival holidays. These differ across states, so a company with offices in several states needs a list per location.
- Shift patterns, which decide what "odd hours" means. A plant with night shifts posts stores receipts at 3 a.m. all year.
- Time zones for shared service centres or group teams. A group finance team in another country may post in what looks like the middle of the night locally.
- Close calendars. Month-end and year-end closes often run through weekends by design. Ask for the close schedule and who was expected to work on those days.
Load these into the test as lookup tables. A weekend or holiday flag then means "outside this client's own working calendar", not "outside a generic calendar".
Sorting hits into useful groups
After the test runs, sort the hits before sampling anything.
- Explained by calendar or process. Shift postings, scheduled close-weekend postings, automated interface batches that run at night. Note the explanation and move on.
- Posted by users who normally work these times. Compare each user's pattern with their own history. A person who always posts late is less notable than a person who posted at night for the first time in the year.
- Posted by users who rarely or never post. An executive, a director or an IT administrator with posting rights who makes entries on a holiday is worth a question.
- Combined with other flags. Manual, round, large, near year end, to unusual account combinations, or reversed later. This is the group to examine first.
Also watch for bursts: many entries by one user in a short window just before the ledger is locked or just before a reporting deadline.
Questions to ask
Keep questions neutral and specific. For a chosen entry:
- Why was it made at this time rather than the next working day?
- Who asked for it and who approved it?
- Where is the supporting document and when was that document dated?
- Is the user's access normal for their role?
Record the answer and check at least one independent fact. An answer such as "we were closing the books" is plausible but does not substitute for support.
A worked example (invented)
A manufacturer works a six-day week and treats Sunday as the weekly off. The auditor runs the test on entry dates and gets 480 Sunday or holiday hits for the year. After loading the client's calendar, which shows two festival Sundays when the plant ran a special shift and a close weekend in April, 430 hits are explained, mostly by automated payroll and stores batches run by a system user.
Fifty hits remain. Thirty come from the same two accounts staff in the last week of March, consistent with the close. The last twenty were posted by the finance head's user ID on two public holidays in October and November, all manual, all to a single reserve account, with narrations that read "adjustment". The auditor asks for the supporting workings and for the approver's identity. All figures are invented; the shape, 480 down to 20, is typical of how calendar-aware testing narrows the field.
Limits of the test
- Remote access and laptops mean honest staff work odd hours more than before.
- A user ID is not always a person. Shared logins make user-based conclusions weak; note them as a control finding.
- Clock and time zone settings on the server may differ from local time. Check before reading anything into an hour.
- The test finds when, not why.
What to write in the working paper
State the date field used, the calendar source, the user population, how hits were grouped, entries followed up and results. Add the limitations above where they apply.
The takeaway
Timing tests are only as good as the calendar behind them. Learn how the client really works, test the entry date rather than the voucher date, and keep the hits that survive for a proper look.
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error