My GPT Workflow Failed at an Ordinary Refund Calculation

The most useful fix I took from a refund-workflow failure was to separate reading the case from calculating the amount. GPT produced a tidy table but treated a deduction as an addition, overstating what remained to refund. That experience changed how I handle ChatGPT math errors: I check the meaning of the numbers before trusting the arithmetic.

The failure came while I was organizing a refund dispute. The source described an amount remaining after an earlier concession had been deducted. The output combined the two amounts instead. Everything around the number looked ready to use, which made the mistake easier to overlook.

I have not reproduced the original customer record here. The amounts below are constructed examples, and the photographs illustrate the problem rather than document that incident. My current model choice for rebuilding this workflow is GPT-6.1 Sol; the lesson from the original mistake is broader than one model version.

The table answered a different question

I had wanted an organized account of the case. What I received included an unsupported interpretation of how much money remained due. Turning messy notes into a polished table had quietly become a decision about the calculation.

That distinction matters because a calculator can execute the wrong operation perfectly. If a model interprets “already credited” as “additional compensation,” running its formula in Python will still produce the wrong business result. The calculation engine cannot decide what a customer note meant.

My first check is therefore a sentence: What does each amount represent, and has any deduction already happened? Only after that sentence is settled do I approve a formula. Asking the model to be more careful would leave this missing decision in the same place.

I would keep the proposed amount in a draft field until the source and formula are checked. A table headed “refund due” can imply a decision has already been made; “proposed remaining refund” leaves the review status visible.

One minus sign, three possible meanings

For a simple ChatGPT refund calculation, suppose a human has approved a total refund entitlement of $120 and confirmed that $20 has already been credited against that same entitlement. There are no other adjustments in this example.

The remaining amount is $120 − $20 = $100. Adding the amounts gives $140, which is $40 above the correct remaining refund. The arithmetic is elementary. Identifying which arithmetic applies is the important part.

The second row catches a different mistake: deducting a credit twice. The third catches a temptation I want the workflow to resist: filling an empty result cell just because the table expects a number.

This is why I treat ChatGPT calculation errors as two checks. First, confirm the interpretation. Then, independently execute the approved operation. A correct total cannot rescue a mislabeled input.

Where I put GPT-6.1 Sol

For rebuilding this process, I would use GPT-6.1 Sol to extract the amounts, preserve their source wording, and propose a rule for review. OpenAI's model documentation describes it as a model for complex professional work and lists Code Interpreter support in the Responses API. That supports my choice of a starting model; it does not establish refund accuracy or prove what happened in my original case.

I would give Sol a narrow job before asking for a customer-ready table. Its first output should contain the case reference, each amount, its currency, the exact supporting phrase, and any unresolved relationship between amounts. “Unknown” is a useful result when the source does not establish the relationship.

I would also keep a source location beside each extracted value: the message date or document section, when supplied. A later note might revise an earlier amount. Without that location, two perfectly transcribed numbers can belong to different versions of the case. If the sequence is unclear, I would ask which approval is current rather than assume the last paragraph contains the latest decision.

Then I would approve the calculation separately. If ChatGPT data analysis is available in the session, I can request code-backed arithmetic and inspect the method. OpenAI's data-analysis guidance recommends reviewing the generated code, outputs, and assumptions. Tool availability can vary by account and settings; without it, I would use a spreadsheet or calculator.

Changing to a more expensive model would not be my first repair. The missing control is an explicit boundary between extracting a statement and authorizing its meaning.

The replacement prompt starts before the answer

My earlier experience led me to stop accepting unconstrained arithmetic inside a prose-to-table task. For a new case, I would begin with this instruction rather than asking for a finished refund recommendation:

Prepare a draft refund review from the supplied case notes.
Do not authorize a payment or infer company policy.

First extract each amount, currency, and exact source phrase.
Label it as approved total, already credited, stated remaining
balance, or unclear. Preserve whether a deduction has already
been applied. Do not calculate in this first pass.

List missing or contradictory facts. If an amount's meaning
or relationship is unclear, mark HOLD and ask one specific question.

After I approve the field meanings and calculation rule,
show the formula and calculate using an available calculation
tool. Identify the tool and inputs. If no tool ran, say so.
Keep the result labeled DRAFT pending human approval.

The prompt creates a review point, but it does not guarantee compliance. I would still compare the extracted phrases with the notes. A quote can be accurate while leaving out the sentence that changes its meaning.

For recurring work, I would keep separate fields for the source statement, interpretation, approved formula, computed result, and review status. Combining all five into “refund due” makes it harder to locate where the error entered.

The checks that would stop this particular failure

To verify AI calculations, I need a result I can compare against something outside the generated explanation. For the constructed $120 case, I would enter the confirmed values into separate spreadsheet cells and use a subtraction formula. I would also check the accounting identity: the $20 already credited plus the $100 remaining must equal the $120 approved total.

That identity checks consistency under the example's assumptions. It cannot establish whether the $120 entitlement was authorized or whether the $20 credit belongs to the same case. Those are source and approval questions.

For a batch, I would add a separate duplicate check. The same credit might appear in both a customer email and an internal note; two mentions do not prove two payments. I would match credit references where available and hold unresolved duplicates. Summing the rows first would preserve the apparent neatness while potentially counting the same event twice. This check addresses the evidence behind the inputs, which a second arithmetic pass would miss.

Before reusing a template, I would check four small cases:

• No prior credit: a $120 approved total with $0 credited leaves $120.

• Partial credit: $120 approved and $20 credited leaves $100.

• Fully credited: $120 approved and $120 credited leaves $0.

• Credit exceeds the total: $120 approved and $130 credited triggers review; I would not silently turn the difference into another refund.

These are proposed acceptance cases, not a claim that I ran a new GPT benchmark. They target the failure I experienced and make the expected behavior visible. For amounts involving cents, I would also specify currency precision and the organization's rounding rule before calculation.

The extra review is the tradeoff

Human review of AI output adds friction. On a single straightforward case, typing two confirmed amounts into a calculator may be faster than preparing a model prompt. I would skip GPT when organizing the source adds no value.

With longer case histories, I would keep its help with extraction while retaining control over interpretation and approval. ChatGPT spreadsheet mistakes become easier to investigate when the source, formula, and result remain separate. The goal is to keep one attractive table from hiding several different decisions.

Among the AI workflow mistakes I now watch for, an unexplained number deserves attention before a polished paragraph. Take one amount in your next AI-generated table and trace it backward: source phrase, approved meaning, formula, independently checked result. If a link is missing, leave that row in draft.