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

Rishabh's comment covers the arithmetic side, so I'll add two schema issues. First, your Swiss receipt test exposes a gap: totalAmount is a bare Number with no currency field, so CHF 45.50 and EUR 45.50 come out identical. For a B2B pipeline that feeds accounting, an ISO 4217 currency field is close to mandatory. Second, dueDate as a plain String has two problems. Receipts like the hotel one usually have no due date at all, and in strict structured outputs every property must be present. Unless the type allows null, the model is pushed to fill something in. And without a format rule, a date like 03.04.2026 can be read as March or April depending on the reader's country. Asking for YYYY-MM-DD or null, plus a separate invoiceDate field, makes the output safe to sort and compare. One more thing worth checking: as far as I know, the image_url input on the chat endpoint takes images, not PDFs, so PDF uploads probably need the file input or a conversion step first.

Good catches, Hayrullah. The nullable dueDate point is the one I'd fix first — a model pushed to invent dates is worse than returning nothing. And thanks for the image_url note; that's exactly the kind of detail that breaks quietly in production.

Spot on with the schema adjustments. Adding an ISO 4217 currency string and enforcing YYYY-MM-DD or null for dueDate and invoiceDate prevents those silent data pipeline breaks where the LLM tries to invent a date for a plain receipt.

Regarding the PDF limitation on the vision endpoint: you are completely correct. My Firebase backend handles a pre-processing step to convert PDF buffers to base64 images before hitting the image_url array, but that is a critical architecture distinction I should have highlighted in the post. I am going to update the article and the API schema to reflect these production hardening steps. Great catches. Thank you!

*** 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.

Agreed on doing that one first, Rishabh. A null tells the pipeline someone needs to look, while an invented date just flows through looking valid.

Thanks for explaining the PDF to base64 step in your Firebase backend, that was the piece I couldn't see from the post. With that conversion in front of it, the image_url path makes complete sense.

Exactly — a null is honest, and it is easy to route to a review queue instead of letting a guessed date flow into accounting. If that queue gets noisy, I would only flag invoices above a set amount and let the rest pass without a due date.

Thanks, the amount threshold is a sensible way to keep that queue from getting noisy. It puts the review effort on the invoices where a missing due date actually costs something.

Search Hashnode