Intelligent Financial Close: case study

This project uses non-confidential finance practice data derived from Excelx content and local sample generation. That choice makes the full workflow public, runnable, and auditable without exposing company records. The close logic is transferable, while the financial outcomes remain modelled rather than client results.

Executive summary

I built Intelligent Financial Close to test how much of a month-end close can be made visible, repeatable, and reviewable with a lean Python stack. The result is a public prototype that combines ETL into SQLite, account-level reconciliation checks, a 2.5σ anomaly filter, a 17-task close dependency tracker, predictive timeline scoring, and Power BI documentation hooks.

The project is meant to show how I would structure the problem from a controller’s point of view, keeping the data flow inspectable, the reconciliation logic explainable, the exceptions visible early, and the close calendar clear enough that bottlenecks can be discussed before they become late surprises.

What I was trying to prove

Many close discussions start by counting days and hours. That matters, but it is usually the visible symptom, not the root problem. In practice, a close becomes painful when finance loses control of moving parts such as late or inaccurate inputs that need to be checked again, supporting detail that is hard to retrace, reconciliations that change after new postings, exceptions that surface too close to reporting, and ownership that becomes unclear once the deadline pressure starts.

That is the difference I wanted to model. A close can be busy without being out of control, and it can be fast on paper while still creating risk if the team cannot close with the same accuracy, evidence, ownership, and review discipline every month. Consistency matters as much as speed.

Anyone who has lived through a close knows the feeling. The numbers may be almost ready, but someone is still waiting for support, a reconciliation has changed after a late posting, or one unresolved account is blocking the next review. The question I wanted to test was whether a close can stay accurate, consistent, and controlled while the work is still moving.

I wanted the prototype to demonstrate three things:

That is why the project does not start with a black-box model. It starts with an inspectable ledger and builds toward the operating questions a finance team actually asks during close.

What I built

The first layer is the data foundation. I used a non-confidential finance-shaped dataset, loaded it into SQLite, and kept the structure simple enough that a reviewer can trace one journal entry from source file to exception output. This was intentional. For this kind of portfolio project, transparency matters more than scale.

The second layer is reconciliation. Each account is checked, assigned a risk level, and routed into either normal processing or manual review. The point is not to remove the controller. The point is to reserve human review for items that actually need judgement.

The third layer is anomaly detection. In simple terms, the Z-score asks whether an account movement looks unusual compared with its own normal pattern. It does not decide that a posting is wrong. It decides that a controller should look at it.

The fourth layer is close orchestration. I modelled the close as 17 sequenced tasks with declared dependencies. This turns the close from a checklist into a small dependency system where one slipping task makes the downstream impact visible.

Key design decisions

SQLite over a warehouse

For this prototype, I chose SQLite because it keeps the system easy to inspect. A warehouse would make sense in a real implementation, but it would also add infrastructure that distracts from the core question of whether the reconciliation and close logic can be followed end to end.

Calibrated anomaly filter

A useful anomaly filter should help a reviewer ask better questions, not create a second close process around investigating every alert. I used a 2.5σ threshold as a balanced rule-of-thumb starting point, stricter than a 2σ screen but less conservative than 3σ, so the logic stays easy to challenge and recalibrate.

On a real ledger, I would not use a single global threshold without calibration. The same movement can mean different things depending on the account.

The threshold would need to be tuned by account type and historical volatility.

Workflow dependencies before dashboards

Dashboards are useful only after the underlying process is clear. I modelled the 17-task close calendar first because the dependency structure is the real operational insight. Power BI becomes the reporting surface, not the source of truth.

Modelled outputs

These figures are scenario outputs, not promises.

The economics are useful because they make the assumptions visible. A finance team could replace the inputs with its own hours, labour cost, exception volume, and implementation budget.

What I trust

I trust the structure of the workflow, from ETL to reconciliation, anomaly review, task sequencing, and reporting. That sequence mirrors how a controller would reason through a close automation problem.

I also trust the design discipline because every threshold, assumption, and dependency is exposed instead of hidden. That is the part I would want a finance director or technical interviewer to see.

What I would review before production

The dataset is safe to publish, but a real deployment would need governed ERP or finance-system exports. That changes the work. Access control, raw-data handling, audit trails, and retention rules become part of the architecture.

The anomaly threshold would also need recalibration. A clean practice ledger lets the concept be demonstrated, but real ledgers contain seasonality, one-off postings, entity-specific behaviour, and account-specific volatility.

Finally, I would add stronger validation around model outputs. The 87% confidence-style output is useful as a scenario signal, but it is not measured precision or recall on a labelled production dataset.

What I learned

The useful lesson is that close automation is not only about replacing manual work. It is about deciding which parts of the process should become more explicit.

Reconciliation rules need to be inspectable. Anomaly thresholds need to be open to challenge. Task orchestration needs dependencies that show operational consequences early. Once those pieces are clear, automation becomes easier to discuss because the system is no longer asking for blind trust.

Future directions

• Multi-entity consolidation layer for group close scenarios.
• Isolation forest baseline to compare against Z-score on the same practice ledger.
• Expanded quarterly and annual close modelling.
• Natural language interface for exception narratives.

Conclusion

The Intelligent Financial Close prototype shows how a lean stack, Python, SQLite, pandas, and scikit-learn, can model the three layers a controller actually touches, reconciliation, anomaly detection, and close-task orchestration. The modelled outcomes are illustrative rather than guaranteed, but the architecture is legible, testable, and available to clone.

Built as an open-source reference implementation. Full source code and documentation are available on GitHub.