DeepSeek API: Validate Arithmetic Before Generating Text

Check the line arithmetic before asking DeepSeek to explain it

DeepSeek API workflows need arithmetic checks before text generation. This Python example validates amounts in integer cents and blocks inconsistent inputs; it is a local test, not a model accuracy benchmark.

An event invoice can add up neatly and still be wrong. In the example below, the supplier's three quoted lines total $234.00, exactly matching the stated invoice total. One line nevertheless charges $80.00 for two units priced at $45.00 each. Multiplying quantity by unit price produces $90.00, making the independently calculated total $244.00. Agreement between two copied totals is not an independent check.

This guide gives an event coordinator a runnable Python checker to find that discrepancy before preparing a request for DeepSeek V4.1 Flash. The useful output is a line-specific exception report and a small drafting brief that the program refuses to produce until the arithmetic passes. All examples are invented conference expenses, and the results come from running the local program. No model generated or approved an invoice here.

DeepSeek can be an optional writing step after a person resolves the discrepancy. It should not decide which supplier price was agreed, approve a payment, or silently replace an invoice. The original document, contract and clarification remain the evidence for that decision. A correct multiplication proves an arithmetic relationship, not that a service was delivered or a charge was authorized.

The $10 mismatch hidden by a matching grand total

The synthetic export contains name badges, room signage and captioning services. These are quantities of whole service units. The checker uses the same five-column schema for every row and one separately supplied invoice total. That separate value matters: comparing the sum against itself would create another reassuring but useless check.

Swipe horizontally to view the full table.

The invoice is not automatically underpaid by $10. Perhaps the supplier meant a discounted line price, or perhaps the quantity or unit price is wrong. The program cannot choose among those explanations. Its finding is narrower and more useful: L3 does not satisfy the declared quantity-times-unit-price rule, so the invoice needs clarification before this workflow creates an ordinary drafting brief.

Keep both versions if a supplier corrects the export. The corrected fixture later in this guide changes L3 to USD 90.00 and the total to USD 244.00 together. That is a deliberately constructed repair for testing, not a statement about a real supplier's intention. A reviewer still needs the actual approved correction for a real invoice.

Define a money format instead of guessing the locale

The code accepts nonnegative USD amounts with exactly two decimal places and positive whole quantities. It converts amount strings into integer cents, then uses integer multiplication and addition. There is no binary floating-point comparison and no tolerance that could hide a one-cent difference. This is a consciously small input contract, not a universal invoice parser.

Amounts such as 2.500, -2.50, 234,00 and scientific notation are rejected. Leading or trailing spaces in numeric fields are also rejected. A European export is not wrong merely because it uses another convention; it requires a separate, reviewed normalization step before entering this particular checker. Do not guess whether a separator represents a decimal or a thousands group.

Python's CSV documentation explains that delimiters and quoting conventions vary. The program uses the CSV parser rather than splitting rows on commas, and opens its in-memory stream with the newline handling used in the documentation. A quoted description containing a comma can remain a single field. Unexpected columns and duplicate line identities are rejected rather than silently ignored.

Fractional quantities, tax, discounts, shipping, multiple currencies and credit notes are outside this contract. If an invoice contains those components, stop and design the corresponding arithmetic rules before using the result. Removing unsupported rows to obtain a passing status would defeat the purpose of reconciliation.

Run the complete checker locally

Save the following as check_invoice.py and run python3 check_invoice.py. It uses Python's standard library, needs no API Key and makes no network request. The included fixture and assertions are part of the deliverable, so a reader can reproduce both the hidden mismatch and the corrected case without purchasing a model call.

"""Offline synthetic invoice check. No model/API request; USD integer cents only."""
import csv
import io
import json
import re

HEADER = ['line_id', 'description', 'qty', 'unit_usd', 'line_usd']
CSV = '''line_id,description,qty,unit_usd,line_usd
L1,Name badges,40,2.50,100.00
L2,Room signage,3,18.00,54.00
L3,Captioning service,2,45.00,80.00
'''

def cents(value):
    if not isinstance(value, str) or not re.fullmatch(r'[0-9]+\.[0-9]{2}', value):
        raise ValueError('Use unsigned USD amounts with exactly two decimals')
    whole, fraction = value.split('.')
    return int(whole) * 100 + int(fraction)

def check(text, invoice_total):
    reader = csv.reader(io.StringIO(text, newline=''), strict=True)
    if next(reader, None) != HEADER:
        raise ValueError('Unexpected CSV header')
    seen, rows, issues = set(), [], []
    for fields in reader:
        if len(fields) != len(HEADER):
            raise ValueError('Unexpected column count')
        ident, description, quantity, unit, quoted = fields
        if not ident or ident in seen or not description.strip():
            raise ValueError('Missing or duplicate line identity')
        if not re.fullmatch(r'[0-9]+', quantity) or int(quantity) < 1:
            raise ValueError('Quantity must be a positive whole number')
        seen.add(ident)
        expected, stated = int(quantity) * cents(unit), cents(quoted)
        rows.append(dict(line_id=ident, expected_cents=expected, stated_cents=stated))
        if expected != stated:
            issues.append(dict(line_id=ident, expected_cents=expected, stated_cents=stated))
    if not rows:
        raise ValueError('No invoice lines')
    declared = cents(invoice_total)
    expected_total = sum(x['expected_cents'] for x in rows)
    stated_sum = sum(x['stated_cents'] for x in rows)
    return dict(currency='USD', line_count=len(rows), line_issues=issues,
                expected_total_cents=expected_total, stated_line_sum_cents=stated_sum,
                declared_total_cents=declared, declared_matches_lines=declared == stated_sum,
                eligible_for_draft=not issues and declared == expected_total)

def draft_brief(report):
    if not report['eligible_for_draft']:
        raise ValueError('Resolve arithmetic before creating a drafting brief')
    return {k: report[k] for k in ['currency', 'line_count', 'expected_total_cents']}

def planned_microcredits(inputs, outputs, rate_in, rate_out):
    if any(type(x) is not int or x < 0 for x in [inputs, outputs, rate_in, rate_out]):
        raise ValueError('Planning quantities and rates must be nonnegative integers')
    numerator = inputs * rate_in + outputs * rate_out
    return (numerator + 999999) // 1000000

if __name__ == '__main__':
    bad = check(CSV, '234.00')
    assert bad['declared_matches_lines'] and not bad['eligible_for_draft']
    assert bad['expected_total_cents'] - bad['declared_total_cents'] == 1000
    try:
        draft_brief(bad)
    except ValueError:
        pass
    else:
        raise AssertionError('Bad invoice became a drafting brief')
    fixed = check(CSV.replace('45.00,80.00', '45.00,90.00'), '244.00')
    assert draft_brief(fixed) == dict(currency='USD', line_count=3, expected_total_cents=24400)
    rejected = 0
    for text, total in [
        (CSV.replace('L2,', 'L1,'), '234.00'),
        (CSV.replace(',40,', ',0,'), '234.00'),
        (CSV.replace(',40,', ',1e2,'), '234.00'),
        (CSV.replace('2.50', '2.500'), '234.00'),
        (CSV.replace('2.50', '-2.50'), '234.00'),
        (CSV.replace('L1,Name badges,', 'L1,Name badges,EXTRA,'), '234.00'),
        (CSV, '234,00'),
    ]:
        try:
            check(text, total)
        except ValueError:
            rejected += 1
        else:
            raise AssertionError('Invalid fixture accepted')
    rates = {'catalog_low': (18333360, 73333440), 'catalog_high': (36666720, 146666880)}
    plans = {key: planned_microcredits(1000, 300, *value) for key, value in rates.items()}
    assert plans == {'catalog_low': 40334, 'catalog_high': 80667}
    print(json.dumps(dict(bad=bad, corrected_brief=draft_brief(fixed),
                         negative_fixtures_rejected=rejected, planned_microcredits=plans), indent=2))

The script deliberately returns a report for arithmetic mismatches but raises an error for malformed inputs. Those are different situations: an understandable invoice may contain a disagreement worth investigating, while malformed rows cannot be interpreted reliably under the declared contract. A production import would also need file-size controls, access controls, accounting conventions and operational review appropriate to its environment.

Read the report without turning it into a payment decision

The executed result has declared_matches_lines: true and eligible_for_draft: false. Its expected total is 24,400 cents, while both the declared total and the sum of quoted lines are 23,400 cents. The exception identifies L3 with 8,000 stated cents and 9,000 expected cents. Those exact values, rather than a generic warning, explain why the superficially consistent total was blocked.

The program also attempted to create a brief from the bad report and confirmed that the function refused it. With the explicitly corrected fixture, it returned {"currency":"USD","line_count":3,"expected_total_cents":24400}. That compact object is the successful local handoff. It is not a model response, proof of tax compliance, or authorization to pay USD 244.00.

Seven negative fixtures were actually rejected: a duplicate identity, zero quantity, exponent quantity, excess monetary precision, a negative unit price, an extra column and a comma-decimal total. This is targeted coverage of the example contract, not proof that every supplier export is safe. CSV syntax errors can also stop parsing; the script does not claim automatic recovery from arbitrary damaged files.

Give DeepSeek a resolved task and an explicit boundary

After the supplier or responsible reviewer resolves the discrepancy, a coordinator may ask DeepSeek to draft a neutral acknowledgment using only approved facts. For example, a proposed request could say: “Draft a short acknowledgment that we received the corrected three-line USD invoice with a reconciled total of 244.00. Do not state that payment is approved or scheduled. Ask the reviewer to confirm the reference number before sending.” This request has not been run here.

The current Orux model form exposes messages, max_tokens and a JSON-object response option for deepseek-v4.1-flash. That verifies the available controls, not successful execution of this invoice-writing task. Use the exact Orux alias from its model page. The model name on DeepSeek's own service is a separate service identifier and should not be copied over as an assumed Orux alias.

The DeepSeek Chat Completions reference documents usage reporting. Count actual returned usage for an executed request; neither CSV characters nor the number of invoice lines establishes token usage. If you need a returned JSON object, validate its fields and values afterward. A form option or a polite-looking response cannot replace that check.

For complementary reading, the museum JSON case examines output validation, while the support-digest guide prepares a different kind of constrained input. This invoice workflow contributes arithmetic reconciliation rather than repeating their extraction or privacy checks.

Compare the two published Orux rate rows

The public catalog on 2 November 2026 contains two dailytimeband rows for this alias. The table uses uncached input and output rates only. It does not assume that a repeated invoice will receive cache pricing, and it does not infer the account's applicable band from the clock. Confirm the current quote and applicable conditions before authorizing a request.

Swipe horizontally to view the full table.

The last column is a planning calculation, not measured token usage or a promised invoice. The program rounds each planned request upward to a whole micro-Credit. One thousand requests with exactly those planned quantities would therefore budget 40.334 or 80.667 Credits under that convention. Actual usage, conditions or additional attempts change the result. No account charge was measured for this article.

The vendor pricing page describes its own model versions and schedules. Those conditions do not establish Orux's schedule or account quotation. We make no claim that this workflow beats another model's invoice accuracy, and no claim that one service is cheaper under every condition. The calculator exists to make an explicit plan inspectable before any optional request.

Keep reconciliation, drafting and approval as separate records

Retain the original CSV, its stated total, the exception report and the approved correction. Run the checker again against the corrected data, then record the exact brief supplied to the optional model step. This preserves the difference between what the supplier wrote, what the program calculated and what a person approved. A generated acknowledgment should not overwrite any of those records.

If the drafting step introduces a payment date, bank detail, reference number or approval that was not authorized, reject that addition and resolve it through the responsible reviewer. This guide does not present a generated example or claim that a particular prompt prevents such additions. Its completed contribution is the local arithmetic gate and reproducible evidence, ready for a separately reviewed communication step.

Prices and form checked on 2026-11-02. Sources: Orux model, public catalog, Python CSV, Python numeric types, DeepSeek reference, DeepSeek pricing.

FAQ

Q.Does a matching invoice total prove that every line is correct?

No. The demonstrated total matches the quoted lines even though L3 fails quantity-times-unit-price arithmetic. Compare independently calculated line amounts as well as the grand total. The program identifies that exact contradiction; a person must then determine which source value should be corrected.

Q.Did DeepSeek find the USD 10 discrepancy?

No. The local Python program found it, and no model was called. DeepSeek is an optional later drafting step with verified current Orux controls and dated planning rates. The article does not evaluate its invoice accuracy, quality, latency or reliability.

Q.Can I use this for tax or multiple currencies?

Not under the current contract. It covers positive whole quantities and unsigned two-decimal USD amounts without tax, discount or currency conversion logic. Extend and test those rules explicitly, using the relevant approved accounting specification, rather than deleting inconvenient rows or guessing a locale.

Q.Are the Credits figures the price of checking this CSV?

No. Running the local checker makes no Orux request and consumes no site Credits. The table estimates an optional later request with assumed token quantities. Actual model usage and the applicable current quote determine that request's charge, not CSV row count.

Q.What must be reviewed before sending a generated acknowledgment?

Review it against the approved correction and the actual communication authority. A reconciled total does not authorize payment or a payment date. Keep the source report separate, reject unsupported details, and confirm the reference number and recipient before sending any message.