Two Teams, Two Units, No Common Table

What They Missed · Part 03/10

Pasadena, California. 23 September 1999, a few minutes past two in the morning.

In a control room at the Jet Propulsion Laboratory, the navigation team is watching the end of a journey that began more than nine months earlier. Their spacecraft — the Mars Climate Orbiter, built to study the Martian climate and weather — is closing in on the planet. On the screens, everything reads nominal. The main engine burn begins on schedule; the orbiter is to slow itself into orbit around Mars.

Part of the plan is silence. During the insertion, the spacecraft passes behind the planet, and for a stretch of minutes no signal can reach Earth. The room knows the blackout is coming; it is printed in the timeline. The carrier drops — slightly earlier than predicted, someone notes — and the waiting begins.

There is a scheduled moment for the signal to return, when the spacecraft emerges from behind the far side of Mars. The deep-space antennas are pointed and listening. The scheduled moment arrives. Then the one after it. Engineers bring up the backup sequences and begin the quiet, procedural work of searching for a spacecraft.

The antennas listen through the morning. The signal never comes back.

What actually happened

There is no wreckage to examine and no recorder to recover, so the investigation works through paperwork — and finds the cause not on the spacecraft but on the ground, in the seam between two teams.

Lockheed Martin Astronautics in Colorado had built the orbiter and wrote the ground software that computed the impulse of its small thruster firings — routine burns used during the cruise to unload the spacecraft's spinning reaction wheels. The Jet Propulsion Laboratory in Pasadena flew the mission and fed that output file into its navigation models. The interface specification between the two teams said the impulse figures would be delivered in newton-seconds, the metric unit. The software delivered them in pound-force seconds, the US customary unit.

One pound-force second equals 4.45 newton-seconds. So every time the file crossed from one organization to the other, the navigation model absorbed a figure 4.45 times smaller than what the thrusters had actually done. Not once — at every firing, for months. Each individual error was small. The cruise was long. The estimated trajectory drifted away from the real one, and the navigators kept seeing solutions that would not quite settle, without finding the reason in time.

NASA's Mishap Investigation Board later stated the root cause in a single line:

The failure to use metric units in the coding of a ground software file, "Small Forces," used in trajectory models.

The spacecraft reached Mars aimed at an altitude of roughly 57 kilometers; the plan called for roughly 226. At 57 kilometers there is atmosphere. The orbiter — reported at $125 million in that week's coverage, part of a $327.6 million program — either broke apart or skipped off into a solar orbit. Nobody knows which, because nobody heard from it again.

Here is the detail worth sitting with. No one's arithmetic was wrong. Lockheed Martin's numbers were internally correct in pound-force seconds. JPL's models were internally correct in newton-seconds. Two consistent ledgers, both accurate to their own conventions — and no layer anywhere whose job it was to make them speak the same language.

Two correct ledgers, no common table

Every finance team operates the same seam, usually several times a day.

The bank statement arrives in Turkish lira, carrying the bank's own conventions: value dates, running balances, credits that mean money in. The supplier's invoices arrive in euros, carrying theirs: invoice dates, contractual amounts, a sign convention of their own. The ledger holds both, in its own dialect. Each source is internally consistent. Each would pass an audit of itself. In Part 01 of this series, the failure was a line nobody reconciled. Here nothing is hidden and nothing is missing — every number is present and correct — and the comparison still fails.

Because the seam is the comparison itself. A €100,000 invoice meets a lira payment: converted at which rate — the invoice date's, the payment date's, the month-end's? A difference appears: is it a real dispute, or an artifact of two dates and a moving exchange rate? An amount carries a minus sign: is that a refund under one convention and a charge under another? None of these questions is answered inside any single source. They live between the sources — exactly where the factor of 4.45 lived.

The Mars teams had an interface specification, and it said newton-seconds. What they did not have was a layer that verified each delivery against that specification — a control whose only job was the translation. A written convention that nothing checks is not a control. It is a hope.

Before two sources can be cross-checked, they must be translated into one table — one currency, one convention, one definition of what a line means. Normalization is not the dull step before reconciliation. It is the work that makes reconciliation possible, and it has to be someone's job.

What this means for your close

The unit mismatch reads like an aerospace story, but its shape is the shape of a monthly close. Four things follow from it:

• Two internally correct sources can still produce a wrong comparison. Your ledger can be right in euros and your bank right in lira while the match between them is quietly wrong. Consistency inside a source proves nothing about the seam between sources.
• Normalization is a job, and someone has to own it. Which rate source, which date's rate, which sign convention, how a partial amount maps to its lines — if no owner is named, those answers get decided implicitly, by whoever last touched the file.
• Write the convention down where a system can enforce it. The Mars interface specification was written down and still failed, because nothing compared deliveries against it. A convention becomes a control only when a layer applies it to every line, every time, and records that it did.
• Treat small, persistent drift as a signal. The navigators watched solutions refuse to settle for months. In a close, a difference that keeps reappearing in the same corridor is rarely random — it is usually a convention mismatch announcing itself.

The lesson lands in one sentence: before sources can be cross-checked, they must be translated into one table — one currency, one convention. And the translation is not a detail that takes care of itself.

The layer that speaks both languages

This is where a visibility layer stands: not after the comparison but before it. Its first act is not matching; it is translation. Bank lines, e-invoices, and ledger entries are brought into one table. Foreign-currency amounts are converted at a declared official rate for a declared date. Sign and date conventions are aligned. And — the part the Mars story insists on — the convention that was applied is written next to the result, so anyone can check it later. Only then does cross-checking three sources against one another mean anything at all.

iFinances is built in that order. When a euro invoice meets a lira payment, the conversion is not an assumption buried in a formula; it is a visible step, and the resulting FX difference appears as its own explained line instead of dissolving into noise. When a line resists translation — an ambiguous rate, an unexpected sign, a date that fits no convention — it is flagged, with the reasoning attached. The system shows, suggests, and explains. It does not decide. The approval, like the signature on the close, stays human.

Frequently asked questions

Was the Mars Climate Orbiter lost because someone got the math wrong?

No. Both teams' calculations were internally correct — Lockheed Martin's in pound-force seconds, JPL's in newton-seconds. The loss came from the interface between them: the ground software delivered one unit, the navigation models expected another, and no layer verified the translation. The investigation board's root cause points at a file crossing a boundary, not at anyone's arithmetic.

What does normalization mean in financial reconciliation?

Normalization is the work of translating every source — bank statement, e-invoice, ledger — into one table before any comparison: one currency at a declared rate and date, aligned sign and date conventions, one definition of what a line means. Cross-checking becomes meaningful only after that translation. Skip it, and differences turn unreadable: a real dispute and an FX artifact look identical.

Who should own normalization in a finance team?

It should be owned explicitly, not left to habit. In practice that means a named owner for the conventions — which rate source, which dates, which signs — and a systematic layer that applies those conventions to every line and records which one it used. The conventions themselves remain a human decision; the system's role is to enforce them consistently and to show its work.

In Pasadena the antennas listened long past the scheduled moment, and the room slowly understood that the silence was the answer. Every number in every file had been correct all along. What was missing fit inside a single conversion: multiply by 4.45. Two teams, two units, no common table — a spacecraft's worth of consequence resting in the space between two correct columns. Most closes carry a quieter version of that space. The question is not whether your sources are right. It is whether anyone owns the translation between them.

✦ iFinances — See what you're missing.