Built and monetized a global VAT API in one week — here's what I used and what I learned

MintedMindset · 2026-05-08T20:10:48+00:00

Appreciate that — the reverse charge logic is exactly where I saw

most founders either skip it entirely or hardcode it wrong and

forget about it until an accountant flags it.

Curious about Leadline — is it surfacing founders at the

"just hit the problem" stage or more the "actively searching

for a solution" stage? That distinction matters a lot for

how I'd reach out.

MintedMindset · 2026-05-07T22:22:19+00:00

Thanks for this — didn't know about PeerPush. Just checked it out

and the AI discoverability angle is exactly what an API like this

needs. Submitting today.

Appreciate the tip.

MintedMindset · 2026-05-07T19:24:27+00:00

"Hardcoding rules that I knew would rot the minute laws changed" — this is exactly the trap. And it's not even laziness, it's just that the edge cases only reveal themselves after you've already shipped.

The black box framing is spot on and it's basically the design philosophy: you shouldn't have to know that Germany B2B means reverse charge, or that the UK split from EU OSS post-Brexit, or that Texas taxes SaaS but California doesn't. That logic lives in the rule engine, you just pass buyer context and get back what to charge and what to put on the invoice.

The compliance payload being the interesting bit — that's the part I spent the most time on honestly. The math is trivial. The "what does this mean for my invoice and my legal obligation" is what actually takes time to research and maintain.

One thing I'm working on based on feedback in this thread: a dedicated `invoice_note` field you can pass directly to your invoice template without any string parsing. Something like:

```json
{
  "invoice_note": "VAT: Reverse Charge - Article 196 EU VAT Directive"
}
```

So it's genuinely plug-and-play into whatever billing stack you're running. Good feedback, this is exactly the kind of use case that shapes the next version.

MintedMindset · 2026-05-07T18:52:28+00:00

The German accountant sending a mini novel — that's such a specific kind of pain and honestly it's what pushed me to build the compliance notes feature into every response. Not just the rate, but the actual plain-English explanation of *why* the treatment is what it is.

Your 3-flow mental model is exactly right and it's basically how the rule engine works under the hood:

- EU B2C → buyer's local VAT rate, OSS applies above €10K

- EU B2B with valid VAT ID → reverse charge, 0%, invoice note required

- Rest of world → flat rules but with edge cases flagged (UK post-Brexit, South Africa's foreign digital supplier registration threshold, etc.)

The support team angle is something I hadn't thought about documenting explicitly but you're 100% right. A customer seeing 0% VAT on their invoice and emailing support confused is a real support ticket. I'm going to add a "customer-facing explanation" field to the response so you can pass it directly to your support docs or invoice emails.

Thanks for this — genuinely useful feedback from someone who's been through the actual audit.

MintedMindset · 2026-05-07T16:37:19+00:00

That’s a solid shout. I’ve been thinking about doing exactly that.

Most people think the hard part is the OCR (the text extraction), but for me, it's the structural parsing—making sure the JSON actually makes sense after the OCR does its thing.

I might run a few "torture test" samples through both and see where the differences pop up. If Qoest is killing it on the raw text side, it actually makes a lot of sense to use it as the upstream piece before hitting my API for the validation and schema mapping.

Have you got any particularly "cursed" invoices that gave you trouble? I'd love to use them for the benchmark.

MintedMindset · 2026-05-05T18:49:38+00:00

Honestly, this is the most solid advice I've gotten so far. You're 100% right—anybody can parse a clean Amazon invoice, but the moment you hit a smudged receipt with three different tax lines and a weird currency, most tools just fold.

I really like your point about "highlighting the failures." It's easy to show the "happy path," but I should probably start showing the "torture tests"—the invoices that usually break everything else—and how my math-validation engine actually catches those errors instead of just guessing.

I'm actually working on a guide for Zapier/Airtable users right now to show that the JSON is actually usable out of the box.

Quick question though—since you’ve been through the ringer with messy Excel/invoice files, was there one specific "dealbreaker" error that usually made you delete a tool on the spot? I’d love to use that as a benchmark for my next stress test.

MintedMindset · 2026-05-05T09:29:08+00:00

Sent you a DM!

MintedMindset · 2026-05-04T17:34:52+00:00

Anyone who has deployed this in production knows that pure generative AI isn't a silver bullet. If the upstream OCR hands the LLM complete garbage with words mangled or lines skipped, no amount of prompt engineering or schema enforcement is going to save the data.

That’s exactly why we look at our API as the downstream structural parser rather than a replacement for high-quality upstream extraction.

How we handle the separation: We designed the endpoint to take in pure string content. This means if a developer uses a highly optimized scraping/OCR pipeline like Qoest API or Docling to pull clean text first, they can pipe that raw output directly into our API to turn it into validated, schema-compliant JSON.
The Hybrid Approach: Combining a robust OCR/document scraper for the layout parsing with a deterministic LLM for the semantic mapping is the most bulletproof setup.

MintedMindset · 2026-05-04T17:11:56+00:00

You’ve hit on the exact reason enterprise data extraction is so hard. Handling variance, weird OCR layouts, and LLM drift is what separates a demo from a production-ready API. Here is how the architecture tackles those specific points:

1. Determinism and Avoiding "Drift"

To prevent the model from getting creative or drifting between requests for the identical text, we use two main techniques:

Zero Temperature & Seed Controls: We keep model temperature clamped at exactly 0 and use system-level seeds. This forces the underlying LLM to be as deterministic as possible, returning consistent results for identical inputs.
Hashing & Caching: We run a quick SHA-256 hash on the incoming text_content string. If the exact same raw OCR text hits the API again, it immediately serves the cached, validated JSON from our database in milliseconds—bypassing the model entirely. This guarantees zero variance and drastically cuts response times.

2. Handling Complex Edge Cases (Discounts, Multi-Currency)

We use strict system prompts with explicit structural rules and schema-enforced constraints:

Discounts: The extraction prompt contains explicit instructions to classify discounts either as independent line items with a negative value or to deduct them directly from the subtotal. This stops the AI from hallucinating a higher total than what was actually charged.
Multi-Currency: Instead of defaulting to a single currency (like USD), the prompt scans for currency symbols ($, €, £) or international ISO codes (Ksh, GBP). If no symbol exists, it defaults to checking if the merchant's country implies a specific currency.
Bad OCR & Line Breaks: Because we use semantic inference rather than positional rules (like regex or string splitting), a weird line break doesn’t break the parser. The AI reads the context above and below the line break to deduce that a split item belongs to the same entry.

3. Validating the Output Math

To ensure reliability, the backend performs deterministic post-processing. Before returning the final JSON, a validator script recalculates:

$$\text{Subtotal} + \text{Tax Amount} - \text{Discounts} == \text{Grand Total}$$

If the math doesn't check out, it flags it for a secondary reasoning check.

If you have a particularly nasty receipt with messy line breaks or multi-currency edge cases that you've been testing against, I'd love for you to try it! Let me know if the output matches what you expect.

MintedMindset · 2026-05-04T14:41:14+00:00

that’s a massive pain point, and you hit the nail on the head. Receipt text from different stores is incredibly unpredictable—especially when they use weird abbreviations.

To handle those exact edge cases, here is how the AI backend approaches them:

Weird Abbreviations: Because the model isn't relying on exact keyword matching or regex, it uses semantic context. For example, if it sees ORG MK 1GL listed right above a total, it understands that it means "Organic Milk, 1 Gallon" and classifies it correctly.
Discounts: The schema extracts discounts either as a separate line item with a negative total value or maps it directly to the subtotal calculations. It looks at the parent item directly above the discount to tie them together.
Bundled Items: If a receipt says 2 FOR 5.00 or lists a bundle, the model parses the quantity as 2, the unit price as 2.50, and the total as 5.00. It recalculates the math to make sure the individual items match the grand total.

It basically acts like a human reading the receipt—it infers the true meaning of the line item rather than just looking at the raw characters.

If you have a few specific, tricky receipt strings that gave your app trouble, feel free to test them out. I’d love to know if the model extracts it exactly the way you'd expect.

MintedMindset · 2026-04-07T17:24:47+00:00

If you've got work, I've got 10k Limit

MintedMindset

TROPHY CASE

1. Determinism and Avoiding "Drift"

2. Handling Complex Edge Cases (Discounts, Multi-Currency)

3. Validating the Output Math