On-device · LV · EE · LT

Scan receipts.
Autofill insurance claims.

An SDK that reads receipt photos and fills in insurance claims, so users don't have to enter anything manually. It runs fully on-device and their data never leaves the phone.

Recognized fields

  • Date
    2026-03-14
  • Document no.
    LV-4471828
  • Provider reg. no.
    40003221109
  • Provider name
    Veselības centrs 4
  • Total amount
    45.00 EUR
  • Service category
    Rehabilitācija

VESELĪBAS CENTRS 4

PVN reģ. Nr. LV40003221109

Datums2026-03-14
Čeka Nr.LV-4471828
Fizioterapija45.00
KOPĀ45.00 EUR

reading · on-device

Fully offline · iOS, Android & Flutter

Optimized
for Latvian, Lithuanian & Estonian markets
On-device
data processing
99%
field accuracy
~0.8 s
receipt read time

What it reads

The five fields your claim form needs, read straight off the receipt.

Built for Baltic receipts

It knows Latvian, Estonian and Lithuanian receipts inside out. Diacritics, local formats, even faded thermal print that trips up generic OCR.

  • Date

    The date field on the receipt.

    2026-03-14
  • Document no.

    The receipt number, for the claim record.

    LV-4471828
  • Provider reg. no.

    The registration number of the issuing provider.

    40003221109
  • Provider name

    The service provider name visible on the receipt.

    Veselības centrs 4
  • Total amount

    The total paid, in EUR.

    45.00 EUR

Per-insurer categorization

Every receipt is assigned to your claim categories.

Claim SDK identifies the service on the receipt and maps it to the category list your submission form uses. Each insurer defines their own.

On the receipt

Datums2026-03-14
Čeka Nr.LV-4471828
Fizioterapija45.00service
KOPĀ45.00 EUR
Claim SDK

Your claim categories

  • Ģimenes ārsta apmeklējums
  • Konsultācijas
  • Izmeklējumi, analīzes
  • Rehabilitācija
  • Zobārstniecība

Compare

Everything a cloud receipt SDK does, without the cloud.

Claim SDK
Runs on-device
Always
Data leaves the phone
Never
Baltic-country tuned
LV · EE · LT
Receipt read speed
~0.8 s
Added app size
Only ~35 MB
Per-scan fee
None
Service categorization
Your categories, per insurer
GDPR
By architecture

Cloud receipt SDKs

Runs on-device
No, processed in the cloud
Data leaves the phone
Every scan
Baltic-country tuned
Generic
Receipt read speed
2–5 s + network
Added app size
~40 MB + network
Per-scan fee
From ~$0.05 per scan
Service categorization
No
GDPR
DPA + data residency

Why Claim SDK

Built for insurance claim intake.

Claims autofill in ~0.8 s

All five claim fields are read straight off the photo. Users just confirm.

Built for LV · EE · LT

Diacritics, local formats and faded thermal print read at 99% field accuracy.

100% on-device

The receipt photo never leaves the phone, so OCR adds no GDPR headache.

Per-insurer categorization

Receipts are sorted into the claim categories your own form uses.

One flat annual price

Unlimited scans, users and devices. Cost stays flat as volume grows.

Integrates in an afternoon

One SDK for iOS, Android and Flutter. It drops into the app you already have.

How it works

From receipt photo to claim data in three steps.

  1. Step 1

    Capture

    Your app takes the photo. Built-in quality checks catch blur and glare before reading.

  2. Step 2

    Read on the phone

    Claim SDK reads the receipt right on the device. No network, nothing uploaded.

  3. Step 3

    Autofill

    Claim-ready data drops straight into your form, field by field.

The data it returns

scan_result.jsonjson
{
  "fields": {
    "date":      "2026-03-14",
    "number":    "LV-4471828",
    "provider":  "Veselības centrs 4",
    "reg_no":    "40003221109",
    "amount":    "45.00 EUR"
  },
  "category":   "Rehabilitācija",
  "on_device":  true
}

Privacy & compliance

Everything happens on the phone.

No servers and no uploads. The receipt is read inside your app.

Read on the phone

Scanning and reading happen inside your app. There is no Claim SDK server, nothing to host, and nothing to secure.

Only claim data comes out

Your app receives the claim fields as structured data. The receipt photo is never uploaded and never stored.

GDPR-friendly by design

No third party ever touches the data, so the OCR step needs no new DPA and raises no data-residency questions.

Receipt photo

stays on the phone

Claim SDK reads it

inside your app · ~0.8 s

Claim fields

into your form

For developers

Integrate receipt scanning in an afternoon.

  • One C++ core, native bindings

    A stable C API under Swift, JNI and Dart FFI, with identical output on every platform.

  • A stable JSON contract

    Typed fields, no surprises, no schema drift between releases.

  • No backend to run

    It ships inside your app. Nothing to host, scale, or secure server-side.

iOSAndroidFlutter
claimsdk.swiftswift
import ClaimSDK

// One handle, loaded once from the bundled models (~35 MB).
let kit = try ClaimSDK(assetsDir: modelsURL)

// Everything below runs on-device. The image never leaves the phone.
let result = try kit.scan(receiptImage)          // → structured fields
print(result.fields.totalAmount.value)           // "45.00"

// Map the receipt to YOUR claim categories (tunable per insurer).
let category = try kit.predictService(result, in: claimCategories)
print(category.name)                             // "Rehabilitācija"

Pricing

One fixed annual price. Unlimited scans.

One fixed annual price

Per insurer. Budget it once. No metering, no surprise invoices.

Unlimited scans

Unlimited receipts, users and devices.

No per-scan fees

Cloud receipt SDKs start around $0.05 per scan. Claim SDK stays flat as volume grows.

One license. Everything included.

  • Unlimited scans, users & devices
  • iOS, Android & Flutter
  • Updates & support
  • Docs & sample apps for every platform

We reply fast.

FAQ

Frequently asked questions

How do I add receipt scanning to my insurance app?
Embed Claim SDK in your existing iOS, Android or Flutter app. You load the bundled models once, pass a receipt image, and get back structured JSON: document date, document number, provider registration number, provider name and total amount. A typical integration takes an afternoon.
Is on-device receipt OCR GDPR compliant?
Claim SDK runs entirely on the device. The receipt image is never uploaded, and only structured data ever leaves the SDK, so sensitive health-claim data stays inside your app. There is no third-party server, no data-processing agreement to negotiate for the OCR step, and no default storage of the image.
How accurate is the receipt OCR?
Claim SDK reads its target fields at around 99% accuracy on Baltic health receipts, and flags anything uncertain so your app can auto-fill what is solid and route the rest for a quick human check.
Which languages and receipts does it support?
Claim SDK is tuned for Latvian, Estonian and Lithuanian receipts, including diacritics, local registration-number and PVN formats, and thermal-print layouts that generic OCR gets wrong.
Can I scan receipts offline without sending data to a server?
Yes. Every step runs offline on the device. No network connection is required to scan a receipt, and no image or field data is sent anywhere.
Does it work on iOS, Android and Flutter, and how big is it?
Yes to all three. Claim SDK is one C++ core with a stable C API and native bindings for Swift (iOS), Android and Dart FFI (Flutter). It adds about 35 MB to your app and reads a receipt in roughly 0.8 seconds on-device.
How does per-insurer service categorization work?
Beyond reading the fields, Claim SDK maps the service on the receipt to your own claim categories. You supply the category list your submission form uses (each insurer defines their own), and the on-device matcher returns the best-matching category, so claims arrive already sorted into the right bucket.

See it read your receipt

Watch Claim SDK turn one of your receipts into claim-ready data.

A 20-minute live demo on your own receipts, covering accuracy, categorization and how the data is handled.

Runs offline · GDPR-ready · iOS, Android & Flutter

Book a demo

The demo request form loads here.

Tally form pending. Add the URL in consts.ts → FORMS.