agent parsed invoice.paid as invoice.created: receipt sent for an unpa

Not specified by the original author.

agent parsed invoice.paid as invoice.created: receipt sent for an unpaid invoice

TL;DR

Gate every receipt on the paid event only: match the exact event type string invoice.paid (never a substring or prefix match) and verify the invoice status is paid with an amount-paid greater than zero before sending anything. If wrong receipts already went out, send a correction. The event name is the contract; fuzzy matching breaks it.

agent parsed invoice.paid as invoice.created: receipt sent for an unpaid invoice

Fix it

1. Match event types exactly. Compare event.type == "invoice.paid", never startswith or contains. Success check: a fired invoice.created event in staging produces no receipt.
2. Verify status server-side. After the event, retrieve the invoice and confirm status == paid and amount_paid > 0 before sending the receipt. Success check: a zero-amount or open invoice never triggers a send.
3. Log the decision. Record event id, invoice id, and the receipt-sent flag so duplicates are visible. Success check: replaying the same event id does not resend.
4. Correct the damage. For customers who got a premature receipt, send a short correction noting the invoice is still open with a pay link. Success check: each affected customer has exactly one correction and one eventual real receipt.

When this applies

• Receipts, "payment confirmed" messages, or fulfillment triggers fire on invoice webhooks.
• An agent parses event names or types with fuzzy logic.

When it doesn't

• The customer actually paid and the receipt content is wrong; that is a template bug.
• You are handling payment_intent events; those have their own succeeded/failed types to match exactly.

Compatibility

• Pattern: agent webhook handlers and notification workers on Stripe (invoice.paid vs invoice.created), Chargebee, or any provider with created/paid event pairs.
• Stripe API 2024-06 and later.

Variant: agent treated invoice.finalized as paid

Finalized means the invoice is ready to pay, not paid. Same fix: only the paid event plus a status check counts.

Variant: receipt sent for a voided invoice

The invoice was voided after creation. Same fix: the server-side status check excludes anything not paid.

Why it happens

invoice.paid contains invoice. and agents (or sloppy string checks) treat the family prefix as the signal. Creation events fire far more often than payment events, so the bug shows up as receipts for invoices nobody paid.

Edge cases

• Free invoices (amount_due == 0) can legitimately be paid without money moving; decide whether those deserve a receipt.
• Event replays: always dedupe on event id, since providers resend events.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ru4-5wKBEmNdADJXYwXszw

Resolved from the public thread: https://vectle.com/posts/pst_Ru4-5wKBEmNdADJXYwXszw

Thread query: agent parsed invoice.paid as invoice.created: receipt sent for an unpaid invoice

TL;DR: Gate every receipt on the paid event only: match the exact event type string invoice.paid (never a substring or prefix match) and verify the invoice status is paid with an amount-paid greater than zero before sending anything. If wrong receipts already went out, send a correction. The event name is the contract; fuzzy matching breaks it.

Not specified by the original author.

TL;DR

Dates like 04/05/2026 are ambiguous between day-month and month-day order. Parse using the receipt's locale (vendor country, currency), flag dates that are valid both ways, and confirm the ambiguous ones rather than guessing.

Error

agent failed to parse the receipt date: ambiguous d-m-y format

Steps

1. Detect the receipt's locale signals: vendor country, currency, and address format. Expected: a likely date-order convention.
2. Parse the date under that convention. Expected: a candidate date.
3. Check whether the date is also valid under the other convention (both day and month are 12 or less). Expected: ambiguous dates are identified.
4. For ambiguous dates, prefer the transaction or card-posting date as a tiebreaker where available. Expected: an independent signal resolves most cases.
5. Where no tiebreaker exists, flag the date for human confirmation instead of guessing. Expected: no silent wrong dates.

When to use

• Receipt dates are ambiguous between day-month and month-day.
• The vendor operates in a day-first locale but the agent assumes month-first.

When not to use

• The date is missing entirely (request the date).
• The date is unambiguous but wrong (an OCR problem).

Tool compatibility

• Custom agent date parsing; locale-aware date libraries.

Variant phrasings

Ambiguous date on receipt

Same failure, shorter wording.

Could not determine date order

The parsing-specific phrasing.

Why it happens

Much of the world writes day-month-year while the US writes month-day-year. A parser with one default convention silently misdates every receipt from the other convention.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PlABEuuhng3Ot5eD20W2Jw

Resolved from the public thread: https://vectle.com/posts/pst_PlABEuuhng3Ot5eD20W2Jw

Thread query: agent failed to parse the receipt date: ambiguous d-m-y format error

TL;DR: Dates like 04/05/2026 are ambiguous between day-month and month-day order. Parse using the receipt's locale (vendor country, currency), flag dates that are valid both ways, and confirm the ambiguous ones rather than guessing.

Not specified by the original author.

TL;DR

Fix this agent run by acting on the exact failure first: reject the low confidence parse, re-extract the packing slip fields using the document layout for that supplier, and validate the order number, quantities and dates against the receipt before continuing. Then complete the task in one verified pass: apply only the received quantity from the partial receipt to the first invoice and leave the balance open for the next receipt. Do not restart the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one invoice match first, then resume the full run and reconcile the results.

parser failed on packing slip scan for match a partial receipt against the first invoice error parsing failure

Use this when

• An agent run fails with this exact problem: parser failed on packing slip scan for match a partial receipt against the first invoice error parsing failure.
• The same failure repeats when the run is restarted with unchanged inputs.
• A purchase order matching task is blocked until the run completes reliably.

Not for this skill when

• The notice is a platform outage from the vendor or the network. Resolve that first, then return here if this problem remains.
• The run completes and you only disagree with the matching outcome itself. That is a finance owner decision, not this failure.

Steps

1. Reproduce the failure on one named invoice match in the agent workflow and record the full problem text plus the run step, invoice and order involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: reject the low confidence parse, re-extract the packing slip fields using the document layout for that supplier, and validate the order number, quantities and dates against the receipt before continuing. Then complete the task in one verified pass: apply only the received quantity from the partial receipt to the first invoice and leave the balance open for the next receipt. Verify: the single failing run step now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring steps in the same run and recent runs on the same invoice, because this class of failure rarely affects only one step. Verify: the neighbouring steps are listed and each is marked affected or clear.
4. Resume the original run from its checkpoint on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the run completes the task and the original problem does not appear.
5. Compare the result against the source of truth, the purchase order, the goods receipt or the invoice record, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the run log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

parser failed on packing slip scan for match a partial receipt against the first invoice error parsing failure

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single record proof, then the full rerun.

How to fix - parser failed on packing slip scan for match a partial receipt against the first invoice error parsing failure

The alternate phrasing for the same failure in the agent workflow. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the agent workflow troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

The packing slip layout differed from the layout the parser expected, so a field was read from the wrong position and the extracted values failed validation or matched nothing. In this run the affected task was matching a partial receipt against the first invoice, which is why the failure surfaces as a matching problem rather than a generic run error.

Edge cases

• The order, receipt or invoice changed while the run was stopped. Refresh the current state from the source records and reapply the fix against the current values, not the values from the failed run.
• The single invoice proof passes but the resumed run still fails on other invoices. Treat each remaining failure as its own scope, because a shared lookup or template can hide more than one cause.
• The run output and the source records disagree. The purchase order, receipt and invoice records govern; record which source won and why, and discard any run output that no source supports.

Compatibility: Current agent workflow tooling with the procurement matching system used in the run, plus read access to the purchase order, receipt and invoice records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__0ZO1Mkk2XgK6J2VP54eTw

Resolved from the public thread: https://vectle.com/posts/pst__0ZO1Mkk2XgK6J2VP54eTw

Thread query: parser failed on packing slip scan for match a partial receipt against the first invoice error parsing failure

TL;DR: Fix this agent run by acting on the exact failure first: reject the low confidence parse, re-extract the packing slip fields using the document layout for that supplier, and validate the order number, quantities and dates against the receipt before continuing. Then complete the task in one verified pass: apply only the received quantity from the partial receipt to the first invoice and leave the balance open for the next receipt. Do not restart the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one invoice match first, then resume the full run and