A small source ledger makes reporting easier to check

Cormac Anstruther — Sun, 15 Nov 2026 16:22:37 +0000

A business story can begin with one announcement and quickly become a folder full of almost identical documents. There is a presentation, a revised presentation, a spreadsheet and a statement that quietly changes a date. For a reporter, finding a number again can take longer than finding it the first time. A small source ledger is a useful software project because it tackles that ordinary problem directly.

The starting point is a plain CSV file. Give each source a stable identifier and record its title, publisher, original address, retrieval date and local filename. Add a short note explaining why it matters. Keep the original document separately. The ledger should help someone reach the evidence, rather than become a substitute for reading it. A simple spreadsheet is enough to maintain the first version.

Separate collection from interpretation

A short script can check whether required fields are missing, spot repeated addresses and list files that are no longer present. Those are mechanical checks with clear answers. Whether a company has met a promise is a different question. That needs definitions, context and, often, a conversation. Keeping those tasks separate makes the automation easier to trust and the reporting easier to explain.

For dates, choose one written format, such as year, month and day. For amounts, store the original value beside a separate currency field. Avoid silently replacing source values with converted figures. If a comparison needs a calculation, save the formula and its assumptions in another file. The next person should be able to reconstruct the step without guessing which exchange rate or reporting period was intended.

Keep useful changes visible

Version control can help with the ledger and small scripts. A concise commit message might explain that a document was replaced after the publisher issued a correction. Large source PDFs can live outside the repository, with filenames recorded in the ledger. Confidential notes and personal contact details need their own access controls; a public repository is unsuitable for them. Before sharing anything, inspect the files being included.

A checksum adds another modest safeguard. It identifies the particular file that was reviewed, even when two downloads share the same name. It does not establish that the document is true. It simply answers a narrower question: are these bytes the same? That distinction matters when an apparently unchanged link starts serving a revised report.

Make the handover boring

The best finishing touch is a short README. Explain how to open the ledger, run the checks and understand the status labels. Include one invented example so that a colleague can try the process without touching live research. Record known gaps openly. An unavailable attachment should remain an unavailable attachment, rather than disappear from the list.

This system need not become a large application. A readable table, a few checks and a clear folder structure can already save repeated work. More importantly, they leave a trail between a published sentence and the material behind it. Software earns its place in reporting when it makes that trail easier to follow, question and correct.

DEV Community: Cormac Anstruther

A small source ledger makes reporting easier to check

Separate collection from interpretation

Keep useful changes visible

Make the handover boring