Set Up an Intake Log That Records Every File

This course prevents two failures.

1. A period counted twice. An extract is a file exported from a system such as a ledger or sub-ledger. Say the March sales ledger extract is loaded on 3 April. On 5 April a colleague thinks the load failed and loads the same extract again. March now appears twice in the quarter.
2. A failed file reaching the total. A payroll extract arrives missing a cost-centre column. Someone notices but is busy, and the file still gets added to the total.

Both failures usually go unnoticed for the same reason. Nothing records what arrived, what was checked and what was used. The total looks plausible, so nobody asks. By the time someone spots it, the report has gone out.

The fix starts with an intake log. This is a simple spreadsheet with one row for every file that arrives. It shows what came in and what happened to each file. Use the sliders to see how much one reload adds to a total.

The intake log has one row for every file received. That includes files you later reject and files you block as duplicates. A log that holds only the good files can't show you what went wrong.

In practice, three AP extracts arrive for March:

• the original on 3 April
• an accidental resend of the same file on 4 April
• a corrected reissue on 10 April

All three get a row. The resend will later be blocked and the original may be replaced. You can only explain that to a reviewer if every arrival was written down.

The rule that protects your totals follows from this: a file that is not in the log does not go anywhere near a total. If someone finds an extract on their desktop and it has no log row, it is not used. It gets logged first, then it goes through the same checks as everything else. No exceptions for urgent files or trusted senders. Those are often the files that cause the double count.

Each row records the same details, so files can be compared and filtered. Set up these column headings in your log:

• File name: exactly as received, for example AP_subledger_2024-03.csv
• Source: the system or producer, for example "AP sub-ledger, exported by Treasury team"
• Reporting period: the month or period the data covers, for example 2024-03
• Currency: for example EUR
• Units: the scale of the amounts, such as units or thousands. A file in thousands read as units is out by a factor of 1,000.
• Row count: the number of data rows, excluding the header
• Receipt time: the date and time the file arrived, for example 2024-04-03 09:12
• Status: where the file stands now (covered shortly)

Add two more:

• Logged by: who made the entry
• Notes / reason: why a file was rejected, blocked or superseded, or anything unusual

Match each field to what it records.

When you fill in period, currency and units, record what the file itself carries, as found in the file. Don't record what you expected it to carry. The difference between the two is exactly what the next lessons check.

In practice, you expect the March AP extract in EUR, in thousands. You open AP_subledger_2024-03.csv and see this:

• the period column says 2024-02
• the amount header says USD
• there is no thousands marker, so amounts are in units

If you type "2024-03, EUR, thousands" because that's what the file name suggests, the mismatch disappears. The wrong file then looks fine. Instead, type what you found: 2024-02, USD, units. Add a note: "File name says March, contents say February."

The file name is a label someone typed. The contents are the evidence. Where they disagree, log the contents and note the disagreement.

Every row has exactly one status, chosen from a fixed list:

• Received: logged, not yet checked
• Accepted: passed checks and may feed a total
• Rejected: failed checks and is kept out
• Blocked: a duplicate of a period already accepted
• Superseded: an accepted file later replaced by a confirmed reissue

Apply it with a dropdown so nobody can type anything else. In most spreadsheet tools this is called data validation with a list. Point it at the five values.

Free text breaks the log. If one person types "OK", another "accepted", another "fine – used", a filter on Accepted misses two of the three. Later you will check that only Accepted files feed each total, and that check only works if the status is consistent.

Flip the cards to test yourself on each status.

Three habits keep the log trustworthy.

Log on arrival. Add the row as soon as the file lands, with status Received. Do this before the file is copied, loaded or used for anything else. If you load first and log later, the busy days are when logging gets skipped.

Open it only to read. Look at the file only to read the details you record: period, currency, units and row count. Don't fix a column, re-save it or sort it. An edited file is no longer the file that arrived.

Never delete a row. When a file turns out to be wrong, change its status and add a note. For example: "Rejected: cost-centre column missing, 2024-04-04." A deleted row erases the evidence that a bad file came in and was kept out. Months later, a reviewer will want to see exactly that.

Put the intake steps in the order they should happen.

Keep the intake log in the shared folder your team already uses. Don't keep it on one person's desktop or in a new tool nobody checks. Anyone who receives a file must be able to log it, and a reviewer must be able to find it.

Keep arriving files in their own folder, separate from accepted data. A simple layout:

• Intake/Incoming: every file lands here first
• Intake/intake_log.xlsx: the log
• Accepted: only files with status Accepted

This separation matters because the total is built from whatever sits in the accepted area. If incoming files land straight in the folder that feeds the report, a reloaded March extract is already in the total before anyone has logged it. Keeping incoming separate means nothing reaches the total by default. A file has to be logged and accepted first. The next lessons add a separate place for rejected files and the checks that decide each status.