Integrating MO Gas Tax Back: receipts in, MO4923-H claims out

Every gas receipt a Missouri driver photographs in MO Gas Tax Back becomes a small structured record — purchase date, gallons, seller, the Missouri fuel tax paid — and the app's OCR pass fills those fields in for them. Receipts pile up all year. They feed one document: the Missouri Highway Use Motor Fuel Refund Claim, Form 4923-H, which the app generates and the driver mails to the state. The deadline is unforgiving. Per the Missouri Department of Revenue, a fiscal year's claim can only be filed July 1 through September 30. That shape — a continuous stream of small records collapsing into one seasonal filing — is what an integrator actually has to handle, and it is the thing this page is about.

The bottom line: the data worth syncing here is not a bank feed, it is a year-long pile of receipt records the user already owns, plus the claim the app assembles from them. We reach it by mapping the app's own client-to-server traffic against a consenting account, and we build the integration around the seasonal deadline rather than pretending capture and filing happen at the same time.

What the app records, receipt by receipt

The surfaces below mirror what the app stores and what Form 4923-H needs to be valid. Per the Missouri DOR, a 4923-H worksheet is built per vehicle and lists, for each purchase, the VIN, the date, the gallons, and the seller's name and address — so the app's data model has to carry exactly those things.

Screens from the app

Three store screenshots, shown as captured. They are useful for confirming field labels and the capture flow before a single line of mapping code is written.

Getting the data out, under the user's authorization

Pick the route by how much of the year you need to see, and by how much effort you can spend.

Authorized interface integration (recommended)

We map the app's login, session and data calls against an account whose owner has authorized the pull, then read the live receipt list, the parsed fields, the vehicle records and the generated claim. This is the route that gives you the whole stream as it grows, which is what the real-time push model needs. Effort is moderate; durability is good as long as we re-check the mapping when the app ships a new client version, which we account for in maintenance.

User-consented credential access

For a single driver or a small set, the user signs in through our flow and we pull on their behalf, per capture or on demand. Lighter to stand up than a full traffic map, and a good fit when you only need one season's data for a known set of users.

Native export of the finished claim

The app's own output — the completed 4923-H and its supporting statement — is itself an export. If all you need is the final filed claim, parsing that document is the cheapest path. It is also the most lossy: no raw receipt images, no per-capture timestamps, and it only exists once the driver finalizes, inside the filing window.

For most integrators the first route is the one to build on, because the value is in the receipts as they accumulate, not the single document at the end; the export route is worth keeping as a cheap reconciliation check against what you ingested.

What lands in your repo

Everything here is tied to this app's actual surfaces, not a generic kit.

• Runnable client, Python and Node.js. Authenticates against a consenting account and reads the receipt list, vehicle records and the generated claim, normalized to the schema in the next section.
• Webhook handlers. Receivers for the captured-receipt and finalized-claim events, with signature verification and the duplicate-collapse logic already wired in, so a re-photographed receipt does not land twice.
• Automated tests. A suite built from real captured receipts that asserts the parsed gallons, fuel tax and seller, and the per-fiscal-year refund math against the SB 262 schedule.
• Sync design. A continuous push for new captures, a backfill for the season's history, and a reconciliation against the finalized 4923-H before the September deadline.
• An OpenAPI/Swagger description of the surface we mapped, for your own client generation.
• A protocol and auth-flow report covering the token and session chain we observed during the build.
• Interface documentation plus data-retention guidance for the SSN/FEIN and VIN fields.

A receipt, end to end

Illustrative shapes — endpoint and field names are confirmed against a consenting account during the build, not guessed. A capture arrives as an event; the handler values it against the fiscal year's refundable rate and writes it once.

POST /hooks/mo-gas-tax-back
X-OFL-Signature: t=1718000000,v1=8a1c...

{
  "event": "receipt.captured",
  "claim_period": "FY2026",            # selects the refundable rate
  "receipt": {
    "id": "rcpt_8f21",
    "purchased_on": "2025-08-03",
    "seller": "Casey's #1147, Columbia, MO",
    "gallons": 11.842,
    "price_per_gallon": 3.099,
    "mo_fuel_tax_paid": 3.51,           # parsed off the receipt
    "vehicle_vin": "1FTEW1E84MFA00000", # sample VIN
    "image_ref": "blob://rcpt_8f21.jpg",
    "ocr_confidence": 0.93
  }
}

# Per the SB 262 schedule: refundable cents per gallon by fiscal year.
REFUNDABLE = {"FY2024": 0.075, "FY2025": 0.10, "FY2026": 0.125}

def handle(req):
    verify_signature(req.headers["X-OFL-Signature"], req.body)  # reject on mismatch
    e = req.json
    if e["event"] != "receipt.captured":
        return 204
    r = e["receipt"]
    rate = REFUNDABLE[e["claim_period"]]
    est_refund = round(r["gallons"] * rate, 2)
    # A driver can photograph the same receipt twice; collapse on the triple.
    key = (r["seller"], r["purchased_on"], r["gallons"])
    ledger.upsert(key, {**r, "est_refund": est_refund})
    return 202

Low-confidence parses keep their image_ref so a human or a second pass can correct gallons or the tax figure before the claim is assembled. The refundable rates above are the increase amounts SB 262 phases in — 2.5 cents in the first refund year rising toward 12.5 cents — so a receipt is always valued against the rate in force on its purchase date.

Where this plugs in

• An accounting practice aggregating many clients' captured receipts into one ledger, each record pushed as the client photographs it, instead of a scramble of PDFs every August.
• An employer or fleet reimbursing drivers: sync each driver's gallons and computed refund, and use the finalized 4923-H total to true up reimbursement.
• A tax-prep product that ingests the assembled claim to cross-check totals and flag missing months while the July–September window is still open.

Who owns this data, and what governs it

No open-banking or account-aggregation regime reaches data like this. Missouri has no general consumer-privacy statute, and the federal personal-financial-data-rights rule the CFPB has been reworking would not cover tax-refund receipts even once it settles — that rule is aimed at the accounts banks and card issuers hold, not at a pile of gas receipts a driver photographed. What the integration actually rests on is simpler: the receipts and the claim are the user's own property, and the user authorizes the pull. We work from authorized, documented, or user-consented access only, keep consent and access records, minimize sensitive fields, and sign an NDA where the engagement calls for one. The claim carries an SSN or FEIN and each worksheet carries a VIN, so those fields get field-level encryption and access logging, and they are dropped entirely for integrators who only need gallons and refund totals.

What we plan for in this build

Two things about this app shape the engineering, and we handle both as part of the work.

The refundable rate moves every fiscal year

The amount you can claim per gallon steps up each year under SB 262, and a fiscal year runs July 1 to June 30. We pin the rate table per fiscal year inside the integration, so a receipt is valued by the rate on its purchase date, and gallons bought either side of a July 1 boundary get split into the right year rather than lumped together.

The filing window is a hard edge

A claim can only be filed July 1 through September 30 following the fiscal year. We design the sync so the integrator's copy is complete and reconciled before that window opens, and we surface a per-claim readiness state — which vehicles and months are accounted for — so a gap shows up in spring, not on the last week of September.

OCR confidence and duplicates

Parsed gallons and tax figures carry a confidence score, and the same receipt can be captured more than once. We keep the raw image alongside the parsed fields, route low-confidence records for a second look, and collapse duplicates on the seller, date and gallons triple before they touch your ledger.

Working with us

A first working pull of the receipt stream usually lands within one to two weeks of agreeing on scope. Source-code delivery starts at $300: you get the runnable Python and Node.js client, the webhook handlers, the tests and the interface docs, and you pay after delivery, once it does what you asked. If you would rather not run anything yourself, the same integration is available as a metered hosted API — you call our endpoints and pay per call, with nothing up front. Either way, you give us the app name and what you want out of its data; access and the compliance paperwork are arranged with you as we go. Tell us what you need on the contact page and we will scope it.

How this was put together

Checked in June 2026 against the app's store listings and the Missouri DOR's own forms and guidance, so the field set and the rate schedule match the live filing process rather than a remembered version of it. Primary sources opened:

• MO Gas Tax Back on Google Play — capture flow, the 20% fee, the no-affiliation notice.
• Missouri Form 4923-H — the per-vehicle worksheet fields the data model has to carry.
• Missouri DOR motor-fuel tax FAQ — the July–September filing window and eligibility.
• Senate Bill 262 — the year-by-year refundable rate schedule.

OpenFinance Lab · integration assessment, 2026-06-14.

Other apps in the same receipt-to-refund space

Same data shape, different front doors — a unified integration would normalize across several of these.

• NoMOGasTax — another Missouri refund app that captures receipts and prepares the same MO-4923H form.
• FuelBack MO — a Missouri gas-tax refund tracker built around the SB 262 increase.
• MO Fuel Tax Refund — a flat yearly-fee 4923-H receipt tracker (its site lists $12 per year).
• Everlance — mileage, receipt and expense tracking with PDF and Excel export; broader reimbursement use.
• MileIQ — automatic drive detection with swipe-to-classify trips; mileage rather than fuel-tax.
• Stride — a free background mileage logger aimed at gig drivers.
• Fuelio — fuel-consumption and cost logging, now under Sygic.
• Drivvo — car expense, fuel and maintenance records.

Questions integrators ask about this one

Can a receipt reach our system the moment it's captured, or only when the claim is filed?

Capture is continuous through the year, but a claim can only be filed July 1 to September 30. We model both: a real-time push of each receipt event into your store as drivers photograph receipts, plus a reconciliation against the finalized MO4923-H before the September deadline so nothing is missing when the window opens.

How are the OCR'd receipt fields like gallons, seller and Missouri fuel tax represented, and how reliable are they?

Each receipt arrives as parsed fields (purchase date, gallons, price per gallon, Missouri fuel tax paid, seller) alongside the raw image reference and an OCR confidence score. We keep the image so low-confidence parses can be re-checked, and we collapse duplicate photos of the same receipt on the seller, date and gallons before they reach your ledger.

There's no open-banking connection here, so how do you actually get the data?

No account-aggregation or open-banking regime covers tax-refund receipts, and the Missouri Department of Revenue is the recipient of the form, not a data source you query. The route is authorized interface integration against a consenting account: the user permits the pull, we map the app's login and session chain, and we read the receipts, vehicle records and generated claim that already belong to them.

The claim carries an SSN and a VIN, so how is that handled in the integration?

We minimize at the edge. An integrator who only needs gallons and refund totals never receives the SSN or FEIN; where identity fields are genuinely required they are field-level encrypted and access-logged. The VIN stays attached to its vehicle worksheet so receipts map to the right vehicle without exposing more than that.