---
id: KB-TD-017
url: https://app.codecontract.io/help/day-to-day/closing-a-file-properly
idioma: en
categoria: trabajo-diario
subcategoria: tareas
audiencia: usuario
nivel: basico
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-TD-016, KB-TL-012, KB-TD-011]
citadoPor: [KB-TD-006]
---

# Closing a file properly

_Finishing the work and closing the file are two different things, and hardly anyone does the second._

**Responde a:** when to close a file · what to check before closing · finished files still open · close or leave open

Almost every file ends without being closed. The work finishes, people move on, and the file stays open forever — until someone counts what is outstanding and gets a figure that means nothing.

## What not closing costs

| Consequence | How it shows |
| --- | --- |
| Counts stop being useful | "We have eighty open" and forty are done |
| Reminders keep going out | To third parties who already delivered, and you look bad |
| The same things get reviewed weekly | Someone looks, sees it is fine, and does not close it either |
| And what is genuinely stuck hides | Among those that only look stuck |

> [!IMPORTANT]
> The fourth does the real damage and is hardest to see. If forty of eighty open files are finished, the five blocked for months do not stand out — they are lost in the noise. **Closing is not tidiness: it is what makes the real problem visible.**

## What to check before closing

1. **That no requests remain open** — That is what keeps sending reminders after the work is done.
2. **That what must be kept is there** — Whatever you will be asked for about this matter in future.
3. **That what was promised is done or noted** — An outstanding commitment in a closed file disappears.
4. **And that any exceptions are closed** — An open exception in a closed file is the worst combination.

> [!WARNING]
> The case worth handling separately: the file that will **not** be completed. It is not closed like a finished one — it is closed saying why. "Closed incomplete: the supplier never supplied insurance and we decided not to work with them" informs; closing it silently leaves whoever looks in two years thinking you forgot.

## When it should stay open

**En corto**

- While there is genuinely something you expect from someone.
- If there is a live deadline that could still move.
- And if it is part of something larger still running.

Outside those three, an open file is not caution: it is noise that will stop someone seeing what matters.

> [!NOTE]
> Closing deletes nothing: the file stays complete, searchable and with its history. All that changes is that it stops counting among what is in progress and stops generating alerts.

**Can it be reopened?**

Yes, and that is normal if something new comes up on that matter.

**What if a minor document is missing?**

Decide: either request it and keep it open, or close it noting it was not requested.

**Who should close it?**

Whoever owned it. If nobody owned it, that was the underlying problem.

## Ejemplos

**A team counts eighty open files and cannot tell which matter.**

- Closes the finished ones and notes the reason on those never completed

→ Twelve genuinely open remain, and the five stuck for months are visible at once.

**A file is treated as closed and two months later a document is missing.**

- Checks what is outstanding before closing
- Records the reason for closing
- Notes whether anything is deliberately left open

→ Closing means the same to the whole team and can be explained months later.

**It is closed and reminders keep going out.**

- Stops the open processes on closing

→ Nobody outside receives requests about something closed.

**Nobody knows why a file was closed incomplete.**

- Notes the reason in the closure itself

→ The decision is explicable.

**The file is reopened and the earlier work is lost.**

- Reopens instead of creating a new one

→ The history is preserved.

**Metrics count dead files as open.**

- Closes what will not progress

→ The numbers say something again.