1. Give the close one shared timetable
A cost close is a coordinated piece of work, not simply the task of the person running a calculation. Inventory, purchasing, production and finance each have inputs that others depend on. Before the period ends, agree one timetable covering the companies and sites in scope, the first calculation and the reporting deadline. Work backwards to reserve preparation and review time. This guide focuses on organising that work. For detailed checks of source records and calculations, use our complementary article, “Before you trust an actual cost figure, check the trail behind it.”
- Set separate deadlines for preparation, calculation, review and approval.
- Account for holidays, absences and named cover.
2. Name owners and make dependencies visible
Assigning a task to “finance” is not enough when a deadline slips. Name its preparer, reviewer and escalation owner, then identify what must happen before it can start. Completion of production confirmations might be a prerequisite for another team's cost review. The canias costing documentation describes relationships across modules; confirm the dependencies that apply to your installation with the process owners. A tracking sheet should show each task's predecessor, expected output and affected delivery. That turns a close meeting from a round of status updates into a discussion of the dependencies holding work back.
- Give every task an owner, a prerequisite and an expected output.
- Distinguish ready, blocked and under-review states.
3. Establish a controlled review baseline
People reviewing reports extracted at different times can believe they are discussing the same result. Give the review copy a version or timestamp and retain its scope and source information. Track documents and changes arriving afterwards in a separate list. An authorised process owner decides which must enter the current review and which can wait for the next agreed run. Establish this baseline as a working procedure, then agree any technical restrictions with the system owner to suit the installation and permissions. Naming a shared file “final” is not a change-control process.
- Identify the review copy, source time and subsequent changes.
- Agree the treatment of late records before they arrive.
4. Escalate exceptions with a clear decision request
Separate blockers from questions requiring review and improvements that can be scheduled later. An escalation should explain the affected records, known facts, likely impact and decision deadline, rather than forward a technical error. If an acceptance threshold is needed, the responsible finance owner should set it. Finding a discrepancy does not automatically give someone authority to accept it. Define who receives the issue if the first owner cannot decide in time. Silence should not become permission to continue. Keep the resulting decision alongside the issue so another team does not have to ask the same question again.
- Assign each exception a decision owner and response deadline.
- Keep the decision, reasoning and affected deliveries together.
5. Control reopening and repeat runs
When a correction affects an accepted result, record the change request first. Which document will change, which reports need another run and which approvals must be renewed? Rerunning the calculation without answering those questions can leave teams working from different versions. Preserve the previous review copy, identify the replacement and explain the difference. Notify owners whose checks must be repeated. If a report has already been circulated, include its recipients in the update plan. Acceptance of the new result should follow completion of the affected checks, rather than merely replacing a file in the shared folder.
- Record the reopening decision, its reason and affected approvals.
- Confirm that previous recipients receive the updated report.
6. Finish with sign-off and a usable handover pack
The handover pack should let a colleague understand what was accepted without reconstructing the close from messages. Keep the approved report version, completed checks, accepted exceptions and decision owners together. Make the final approver and the scope of that approval explicit. Give deferred work an owner and a target date; closing the period must not make open tasks disappear. Afterwards, review which inputs arrived late, which decisions caused delays and which checks were repeated. Carry useful improvements into the next timetable. The aim is a more predictable close, not a larger collection of meetings and documents.
