Comment by Rishabh Mishra on "Building a Resilient B2B Invoice Parser API: Swapping Brittle Regex for Structured LLM Outputs"

Structured outputs fix the shape, not the truth — a total that doesn't equal the sum of the line items still sails through. A cheap deterministic check (line items sum to totalAmount, dates parse sanely) with a re-prompt on mismatch catches most of that without human review.

Excellent point on the deterministic validation. You are exactly right—structured outputs guarantee the schema shape, not the mathematical truth. I am adding a lightweight Node.js middleware check to validate sum(lineItems) === totalAmount before returning the JSON payload. If it fails, it triggers a re-prompt. Appreciate the insight; this is exactly how we prevent silent pipeline breaks.

Glad it helps. One addition: log the failed checks with the invoice ID before re-prompting. That gives you a quick read on which fields the model misreads most often, which is exactly where the prompt needs tightening.

*** UPDATE: Live Upgrades Implemented ***

Thank you to everyone who commented with suggestions and feedback. Based on your input, the Invoice Parser API has been officially upgraded and is now live in production.

Key improvements include: • Native PDF & Image Support: The extraction engine was rebuilt to seamlessly process both direct PDF documents and image-based invoices (JPG/PNG). • Strict Math Validation: The extraction schema now deterministically cross-checks all financial fields (line items sum to subtotal; subtotal + taxes + fees — discounts = total). If the math does not align, the API forces a recalculation to ensure your automated B2B pipelines receive flawless data. • Infrastructure Upgrade: Migrated the Firebase backend to a modern Node 22 runtime for faster, more reliable server processing.

The endpoint is fully operational and ready to be wired into your automated workflows to completely eliminate manual data entry.

Nice to see the math check land. One small gotcha: compare in smallest units (cents, not decimals) and allow a ±1 cent tolerance — tax rounding makes exact equality fail on real invoices.

Search Hashnode