PreviewExtraction is live, with pricing still proposed and billing not live yet. Read the docs or get an API key.
Describe your fields and the rules between them. Every value comes back checked against those rules, with the text it came from. When something doesn't add up, you see exactly where.
total == net + vatTickmarks lists the repairs that would close it. It doesn't pick one; you do.
Doesn't close. Net plus VAT is €121.00 and the total says €112.00. Nothing in the invoice says which is wrong, so all 3 fields come back conflict and no value goes into data.
Closes. The total becomes €121.00, derived from net plus VAT.
Closes. VAT becomes €12.00, derived from the total minus net.
Closes. Net becomes €91.00, derived from the total minus VAT.
The request sends the document text and a schema that names the fields and the rules between them. The response says, for every field, what Tickmarks made of it.
Net €100, VAT €21, total €112. One of those is wrong, and nothing in the invoice says which. All 3 fields come back conflict, with no value in data and the possible repairs listed. A person makes the call.
| Text | Field | Status | Source |
|---|---|---|---|
| Invoice INV-004211 | number | resolved | observed |
| Net: EUR 100.00 | net | conflict | withheld |
| VAT (21%): EUR 21.00 | vat | conflict | withheld |
| Total: EUR 112.00 | total | conflict | withheld |
POST /v1/extractions{
"document": "Invoice INV-004211. Net: EUR 100.00. VAT (21%): EUR 21.00. Total: EUR 112.00.",
"language": "en",
"schema": {
"hydra_schema": "1.0",
"name": "invoice",
"fields": [
{ "name": "number", "type": "string" },
{ "name": "net", "type": "money", "currency": "EUR" },
{ "name": "vat", "type": "money", "currency": "EUR" },
{ "name": "total", "type": "money", "currency": "EUR" }
],
"relations": [{ "id": "sum", "expr": "total == net + vat" }]
}
}{
"data": {
"number": "INV-004211",
"net": null, "vat": null, "total": null
},
"fields": {
"number": { "status": "resolved", "source": "observed" },
"net": { "status": "conflict" },
"vat": { "status": "conflict" },
"total": { "status": "conflict" }
},
"components": [{
"conflicts": [{
"relation": "sum",
"repairs": [
{ "drops": "total", "posterior": 0.392482,
"derived": { "amount": "121.00", "currency": "EUR" } },
{ "drops": "vat", "posterior": 0.333061,
"derived": { "amount": "12.00", "currency": "EUR" } },
{ "drops": "net", "posterior": 0.274457,
"derived": { "amount": "91.00", "currency": "EUR" } }
]
}]
}]
}The extraction's response, shortened to the parts that matter here.
The lease starts on 1 March 2027 and runs for 12 months. It never states an end date, but the relation can compute one. The end date comes back resolved with its source set to derived, and derived_by points to how.
| Text | Field | Status | Source |
|---|---|---|---|
| The lease starts on 1 March 2027 | startDate | resolved | observed |
| and runs for 12 months. | duration | resolved | observed |
| Not in the text | endDate | resolved | derived |
POST /v1/extractions{
"document": "The lease starts on 1 March 2027 and runs for 12 months.",
"language": "en",
"schema": {
"hydra_schema": "1.0",
"name": "lease",
"fields": [
{ "name": "startDate", "type": "date" },
{ "name": "endDate", "type": "date" },
{ "name": "duration", "type": "duration", "basis": "calendar" }
],
"relations": [
{ "id": "term", "expr": "endDate == startDate + duration" }
]
}
}{
"data": {
"startDate": "2027-03-01",
"endDate": "2028-03-01",
"duration": "P12M"
},
"fields": {
"endDate": {
"status": "resolved",
"source": "derived",
"value": "2028-03-01",
"confidence": { "posterior": 0.8827 },
"derived_by": ["d0"]
}
},
"derivations": {
"d0": {
"relation": "term",
"solved_for": "endDate",
"result": "2028-03-01"
}
}
}The extraction's response, shortened to the parts that matter here.
Net €100, VAT €21, total €121. Every value fits the relation, so every field is resolved and data is ready to use as it is.
| Text | Field | Status | Source |
|---|---|---|---|
| Invoice INV-004211 | number | resolved | observed |
| Net: EUR 100.00 | net | resolved | observed |
| VAT (21%): EUR 21.00 | vat | resolved | observed |
| Total: EUR 121.00 | total | resolved | observed |
POST /v1/extractions{
"document": "Invoice INV-004211. Net: EUR 100.00. VAT (21%): EUR 21.00. Total: EUR 121.00.",
"language": "en",
"schema": {
"hydra_schema": "1.0",
"name": "invoice",
"fields": [
{ "name": "number", "type": "string" },
{ "name": "net", "type": "money", "currency": "EUR" },
{ "name": "vat", "type": "money", "currency": "EUR" },
{ "name": "total", "type": "money", "currency": "EUR" }
],
"relations": [{ "id": "sum", "expr": "total == net + vat" }]
}
}{
"data": {
"number": "INV-004211",
"net": { "amount": "100.00", "currency": "EUR" },
"vat": { "amount": "21.00", "currency": "EUR" },
"total": { "amount": "121.00", "currency": "EUR" }
},
"fields": {
"total": { "status": "resolved", "source": "observed" }
}
}The extraction's response, shortened to the parts that matter here.
data.derived_by saying how.Relations like total == net + vat aren't a check run afterwards. Tickmarks uses them to choose between candidate values, so the answer you get is one that fits.
An invoice shows two totals, €121 and €112. Tickmarks returns €121, the only one that equals net plus VAT. When no candidate fits, as in the invoice above, you get a conflict instead.
If the rules can compute a value the document doesn't state, Tickmarks computes it and says so. You always know what was read and what was derived.
A lease starts on 1 March 2027 and runs 12 months. It never states an end date, but endDate == startDate + duration computes one:
"endDate": {
"status": "resolved",
"source": "derived",
"value": "2028-03-01",
"derived_by": ["d0"]
}If the document contradicts itself, Tickmarks doesn't quietly pick a side. It marks the fields as a conflict and shows what each repair would give, so a person makes the call.
Net €100, VAT €21, total €112: all 3 fields come back conflict, with 3 repairs listed. Try them in the loop.
Also in every response: the exact source text for each value, a confidence and a status. Arithmetic is exact, so 0.1 + 0.2 == 0.3 is true, and schemas are type-checked when they compile.
Indie developers, startups and small teams putting document data into a product or an internal tool. Stop writing the checks after the model. Put them in the schema.
And for the people relying on the numbers: finance and legal teams, bookkeepers, freelancers and small businesses. If the total isn't net plus VAT, you'll hear about it.
Tickmarks reads text. For a scan or a photo, run OCR first and send the text; built-in OCR is planned. Scans, photos and PDFs.
Prepaid, 2,000 reads for €10, and 10 free reads for every new account. Most invoices take one read. No contract. How reads add up
See how a schema, a relation and a response fit together, then write the rules your documents already follow.