A new system can have a tidy partner list while old documents refer to codes absent from that list. Some names look familiar and some amounts are blank. Matching similar names and filling empty numbers with zero may look like efficient cleanup. Reviewing this project's migration records led me to ask what that cleanup would remove. A convenient new interface and a faithful account of the past require different decisions. The data model needs room for both.
Missing from the current list does not mean nonexistent
A historical code may be absent because a business closed, a record became inactive or a master list changed. Without establishing the reason, dropping the document removes a real part of the history. Replacing its partner with a similarly named current business can attach that history to the wrong entity. The preserved audit describes retaining codes that no longer appeared in the current master data as historical references rather than silently discarding them.
The useful distinction is between a target available for a new transaction and a target needed to read an old one. Everyday selection can prioritize current partners. Historical detail can show the original code and name alongside the status of any present-day link. An explicit option to include historical references keeps the ordinary picker manageable without making older documents disappear. Visibility in a default search and preservation in the ledger should not be controlled by the same switch.
Unknown is a state, not a convenient number
Putting zero into a blank supply amount makes arithmetic easier. It also asserts that the transaction was free. An actual zero and an amount that has not been established are different facts. The archived report explicitly retains unknown amounts. My criterion is that implementation convenience must not manufacture a business fact. An empty input can be inconvenient to calculate with and still be the most accurate representation of what is known.
A screen can show the subtotal of verified values alongside the number of unresolved rows. If only part of the result is known, the label needs to say that too. In a synthetic three-row example, two known values and one unknown value produce a known subtotal with one unresolved row. Simply skipping the unknown value without an explanation can still mislead a reader into treating the subtotal as the complete amount. Correct storage and understandable presentation have to work together.
Suggesting a relationship is different from confirming it
Normalizing spaces or legal-entity suffixes can help find candidates. Similar names alone do not establish identity. Different businesses can use the same name, roles can change and historical codes may require additional context. A confirmed relationship should retain the original identifier, the evidence used and the person and time associated with the decision. Otherwise a later operator cannot distinguish a verified match from an earlier convenience rule.
I would preserve source rows and store interpreted relationships separately. If a link proves wrong, a new interpretation can then be recorded without rewriting the evidence. Unlinked items also need an ordinary way to be found. Hiding them in an import error file makes them easy to forget. A visible awaiting-classification or unlinked state gives the business a practical queue for resolving them when the missing information becomes available.
Prefer a list that can explain itself
For another application, separate current availability, historical identifier, current linked target and review state. One active flag cannot reliably express all four. It may prevent old records from being read when a partner is disabled, or make an uncertain relationship look confirmed. Search defaults and retention rules are separate product decisions, even when a simple interface presents them close together.
Test the proposed behavior with synthetic examples: an absent historical code, a genuine zero, an unknown amount and two different partners sharing a name. Can each record still be found, and can a reader explain the total? This article is based on selected code and dated reports, not a fresh reconciliation of the company's ledger. Keeping unresolved facts visible is a maker's decision about future work: the next person should be able to see what still needs checking instead of inheriting certainty that the source never provided.