Depends a lot on volume and whether you need accounting-grade structured data (header + line items) or just searchable text. Some things I've learned building this out:

Stack that actually works for invoices:

• OCR: Mistral OCR API has been the best price/accuracy ratio for me — handles messy scans and handwriting way better than Tesseract, and it's cheaper than Textract. Google Document AI Invoice Parser is the premium option if budget isn't a concern.
• Field extraction: Don't try to regex the OCR output. Feed the raw text to an LLM with a strict JSON schema (header fields + a line_items array). Mistral Large, Claude Sonnet, and GPT-4o-mini all work fine. Validate the output with Zod or Pydantic before writing to DB.
• Coherence checks: Always cross-validate qty × unit_price ≈ line_total and sum(line_items) ≈ total_amount. Catches \~80% of silent OCR errors before they hit your ERP.
• Queue: Inngest, Trigger.dev, or plain BullMQ. OCR + extraction easily takes 20-40s, you don't want that in the request path.
• Rate limits: Mistral is 6 req/s on the base tier. Build a proper limiter or you'll hit 429s the first time a user bulk-uploads 50 docs.
• Storage: If you'll ever need semantic search across invoices, store 1024-dim embeddings in pgvector now (mistral-embed or OpenAI text-embedding-3-small). Retrofitting is painful.

Gotchas nobody mentions:

• Line items are where every template-based tool falls apart. A schema-constrained LLM extraction destroys template tools on layout variation.
• PDFs with embedded text: extract directly (pdf-parse, pdfplumber) before falling back to OCR. Saves latency + 90% of the OCR cost.
• If you sync to Xero/QuickBooks: the API expects internal account codes, NOT the text written on the invoice. You need a chart-of-accounts mapping step (can be LLM-assisted, but the user has to confirm it once per vendor).
• Bank statements aren't invoices (debit/credit, not qty × price). If you ingest both, plan separate extraction schemas from day one.

TL;DR: <100 docs/month → no-code (Parseur, Nanonets, Rossum) is fine. Above that, rolling the stack above is cheaper and gives you full control over the accounting sync, which is usually where no-code tools break down.

Disclaimer: I'm the founder of Zerentry - we do exactly this stack in production. Mod, feel free to remove if out of line.