A stock valuation looks like a simple reporting problem. Choose a date, calculate the stock on hand and its cost, then produce a total. But when I started using historical stock figures to compare financial years, the difficult part was not displaying the number. It was deciding how much confidence to place in it.
For a small reseller, stock records accumulate gradually through purchases, sales, returns and corrections. They are useful for running the business day to day, but historical accounting questions ask something different: what did we actually hold at a particular point in time, and how reliably can we value it?
That distinction prompted a change in how I wanted Senado MIS to present stock valuations.
The friction in a perfectly reasonable report
The system already had a custom-date accounting stock report. It could answer the question for a particular date. The problem appeared when I wanted to compare one year-end with another.
I found myself repeatedly generating separate reports, recording the results and mentally connecting the opening balance of one period with the closing balance of the previous one. That is manageable once. As a regular workflow, it is tedious and leaves too much room for transcription mistakes or inconsistent comparisons.
The obvious improvement was an annual overview: a series of periods, each with opening and closing values, and a way to inspect the underlying products. But I did not want to introduce a new calculation simply to make a convenient table. Two screens reporting different stock values for the same date would create more confusion than the new screen solved.
The annual overview reuses the existing historical valuation calculations. Each period’s opening balance comes from the preceding year-end closing balance. The annual view is a different presentation of the same underlying accounting evidence, not a second costing system.
A total is only the start of the question
A year-end total is useful for an overview. It is much less useful when something looks wrong.
Suppose the valuation has changed sharply between periods. Was that caused by purchasing, sales, missing purchase costs or a correction to a historical transaction? An aggregate number cannot tell me. Even a breakdown by category may only narrow the search.
The new Stock Valuations workflow is designed to move from the total towards the records behind it. The page shows category breakdowns and product-level opening and closing quantities, unit costs and values. Search, product links and a flagged-products filter make it possible to move from an unexpected figure to the item that needs investigation.
That is a different way to think about an accounting report. Rather than being the final answer, it becomes the starting point for data cleanup.
I particularly want missing costs, estimated purchase costs and negative historical quantities to remain visible. Hiding these exceptions would make the page look tidier, but it would also make the number appear more authoritative than the underlying data justifies.
Why historical figures can change
There is another important distinction between a calculated historical report and an approved accounting snapshot.
The annual valuations are recalculated from the current ledger. They are not stored as frozen, signed-off year-end balances. If I correct an old purchase record or resolve a missing cost, a report for a previous year may change.
That behaviour is useful during cleanup: corrections flow through to the figures that depend on them. But it has consequences. A figure generated today is not necessarily identical to one exported months ago, even if both describe the same year-end date.
For now, I would rather make that limitation explicit than pretend the report is an immutable accounting record. The page explains that values can be revised as the historical ledger improves.
Eventually, if I use these figures in formal year-end working papers, I may need a separate approval or snapshot process. That is a different requirement from calculating the best current reconstruction of historical stock.
Conflating the two would make the design harder to reason about.
Keeping the calculations consistent
Historical reports have awkward boundaries. A transaction recorded on the last day of a period must fall on the correct side of the year-end. The opening balance for the next period must agree with the previous closing balance. A year-to-date view needs a different endpoint from a completed financial year.
The tests cover these boundaries, opening and closing continuity, and avoiding duplicated sale stock-outs. These are not glamorous test cases, but they matter more than the appearance of the summary page.
The annual request loads the product records, stock movements and sales once, then reuses those inputs across the periods. That is preferable to treating each year as an entirely separate report request, provided the calculation semantics remain consistent.
The view includes financial years ending on 31 March, a calendar-year option and the current year to date. CSV and HTML exports continue to use the existing accounting report. Keeping the annual overview connected to established reporting paths reduces the chance that the new feature quietly develops its own interpretation of the data.
What I want from the report
My immediate aim is not to automate a tax return or produce a polished statement that can be accepted without inspection. It is to make the work of reconciling historical stock more systematic.
I want to see which periods look plausible, which product records are incomplete and where a correction would make the largest difference. The report should make it easy to follow an anomaly back to its source instead of requiring me to compare disconnected exports.
That is also why I am cautious about adding layers of automation too early. Automatically generating a number is straightforward compared with explaining why it is correct. In an operational system, the most useful next step is often not another calculation but a better path from a calculation to its evidence.
The broader lesson is that data quality is part of the reporting workflow, not a separate housekeeping exercise. A report that exposes uncertainty can be more valuable than one that confidently displays a clean total.
For Senado MIS, the annual valuation view is useful precisely because it makes the weaknesses in the historical data easier to see. Once those are visible, I can start fixing them.