Key takeaways
- Seventeen software plans on one account. Sixteen store their price in cents. One newer plan stores it in dollars, with a different kind of id.
- Read side by side, the odd one out looks like a pricing typo, or like a plan never set up with the payment processor. It got escalated as both. It was neither.
- A single flag on each record says which generation it is, and that flag decides how every other field on it should be read.
- The currency fields are identical on both and prove nothing, which is why they are so easy to trust.
- Check whether two records are even the same kind of record before comparing them. And the honest gap left: the newer billing path is verified by configuration, not by a real charge.
We run software plans on a platform that bills our clients. Each plan has a name, a price, a billing period, and an id that ties it to whatever actually takes the money.
Someone pulled the list of plans on one account and something looked badly wrong. Sixteen plans showed prices in the thousands. One showed a price in the low hundreds, sitting beside plans reading twenty nine thousand.
Two readings jumped out immediately, and both were alarming. Either somebody typed dollars into a field that expects cents, which would mean a plan selling for about two dollars. Or the plan had never been connected to the payment processor, which would mean nobody could be charged for it at all.
Both readings were wrong
The sixteen plans store their price in cents. Twenty nine thousand seven hundred means two hundred and ninety seven dollars. That is the normal convention, and sixteen out of seventeen is a convincing majority.
The odd plan stores its price in dollars. One hundred and ninety seven means a hundred and ninety seven dollars. It was correct the entire time, because the platform has two generations of this feature and the newer one changed the unit. Each record carries a flag saying which generation it belongs to, and that one field governs how to read every other field on it.
Once you know the flag exists, everything else about the odd record stops being suspicious and starts being consistent. The id shape is different because the newer generation uses the platform's own ids instead of the payment processor's. There is an extra field naming which account the money runs through, which the older generation does not have and does not need, because it bills through a connection held one level up.
The id shape was what made it look broken, and the id shape was just what a newer record looks like.
The fields that look like evidence and are not
This is the part worth carrying to other systems.
Both kinds of record carry a currency field and a currency symbol, and they are identical on both. Same three letter code, same dollar sign. They tell you the money is in dollars. They tell you nothing about whether the number beside them is dollars or cents.
Which is the trap, because a currency field is exactly where you would look. It is labelled currency. It sits next to the amount. Reading it feels like checking, and it is not checking. The field that actually answers the question is a flag about the product generation, sitting elsewhere in the record, that does not look like it has anything to do with money at all.
Why the escalation was reasonable and still wrong
Nobody was careless here, and that is the useful part. The reasoning went: sixteen records follow one convention, one does not, therefore the one is broken. That is good instinct most of the time, because majority behaviour usually is the house rule.
What it misses is that a majority tells you what is common, not what is correct. If a platform ships a second generation of something and you are mostly on the first, every correct new record is going to look like an outlier on your account until the balance tips.
So the order of operations matters. Before comparing two records, establish that they are the same kind of record. If they are not, a field by field comparison is not a comparison. It is two different documents read with one set of rules.
We confirmed the reading against the platform's own interface, which renders the odd plan at its full price, exactly as the dollars reading says it should. That is the check that ends the argument: look at the surface a human uses and see which number it prints.
The part we did not close
Being honest about what is still unproven beats a tidy ending. No real subscription has ever run through that newer plan. Everything above says the record is correct and the billing route is configured. None of it says money has moved along that route, because nobody has ever paid on it.
Configuration verified and behaviour verified are two different claims. We have the first, not the second, and we are not going to pretend a reading of a record is the same as a receipt. That is a separate job with a real charge in it, and it stays open until somebody runs it.
What this means for your business
The narrow version: if you sell subscriptions through any platform, check whether your plans are all the same generation. A mixed account is normal and quietly changes what your own numbers mean. Anything that reads those prices, a report, a spreadsheet, a proposal, needs to know which kind it is looking at.
The wider version is a habit. When a record looks wrong, the first question is not what is wrong with it. It is what kind of record this is, and whether it is the same kind as the one you are comparing it to.
Three things follow. Find the field that governs how the rest of the record reads, because most systems have one and it is rarely near the fields it governs. Treat a field that is identical across both kinds as no evidence at all, however relevant its name sounds. And check your answer on the screen a human looks at, because that screen already knows.
If you are a marketing automation San Jose business running client billing through a platform you did not build, this is a short audit that stops somebody fixing a price that was never broken.
Want this built for you
We build and audit the billing and automation layer under client systems, and we tell you which parts are proven and which are only configured. Start at optechsol.llc.