three-way match "failed to run" error on 5,000 PO lines: report times out before finishing

TL;DR

A match run over 5,000 lines fails as a batch long before it fails as logic: one slow line, a lock, or a memory ceiling kills the whole run and nothing is saved. Split the run into chunks by vendor or PO date, run the chunks with saved progress, and identify any single poisonous line by binary search instead of rerunning everything. Move the full-volume run to an off-peak window once chunking proves the lines themselves are fine.

three-way match "failed to run" error on 5,000 PO lines: report times out before finishing

Use this when

• The match job errors as failed to run or times out without line-level results.
• Volume is thousands of PO lines, here 5,000, in one run.
• Smaller manual matches for individual invoices succeed.

Not for this skill when

• The run fails instantly even for one invoice. That is configuration or data corruption, not scale.
• The job fails on a system outage window. Retry after the outage; chunking is for repeatable scale failures.

Steps

1. Check the job log for how far the run progressed and whether failure is timeout, memory, or lock related. Verify: the failure mode is named from the log, not guessed
2. Run the match for a small slice, one vendor or one day of POs, and confirm it completes. Verify: a small slice finishing proves the logic works and scale is the issue
3. Chunk the full set into groups of a few hundred lines with results saved per chunk. Verify: each chunk reports its own matched and exception counts
4. If one chunk fails, split it again to isolate the poisonous line or PO, and set that item aside for manual handling. Verify: the bad item is identified without blocking the other chunks
5. Schedule the recurring full run off-peak in chunks with a summary report. Verify: the next full run completes end to end and reports exceptions normally

Variant phrasings

three way match timeout 5000 lines batch fails

The scale-failure phrasing.

match report times out large volume PO lines

Searching by the timeout symptom.

Compatibility: Batch three-way match in SAP, Oracle, NetSuite, and AP automation platforms processing thousands of lines.

Why it happens

Match engines were designed when nightly volumes were smaller. A single run holding thousands of lines in one transaction inherits the worst line's problems: one lock or corrupt record rolls back everyone's progress. Chunking converts an all-or-nothing job into a resumable process where progress is durable and bad data is quarantined instead of fatal. The exceptions do not change; the blast radius does.

Edge cases / pitfalls

• Locks from users editing POs during the run are a common hidden cause. Off-peak chunked runs avoid most contention.
• If one vendor's EDI invoices are always the poisonous chunk, the fix is in that feed's data quality, escalated with the chunk evidence.
• Keep chunk sizes consistent so run times are comparable month to month; a chunk that suddenly doubles in duration is an early warning.

Provenance

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

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

Thread query: three-way match "failed to run" error on 5,000 PO lines: report times out before finishing

TL;DR: A match run over 5,000 lines fails as a batch long before it fails as logic: one slow line, a lock, or a memory ceiling kills the whole run and nothing is saved. Split the run into chunks by vendor or PO date, run the chunks with saved progress, and identify any single poisonous line by binary search instead of rerunning everything. Move the full-volume run to an off-peak window once chunking proves the lines themselves are fine.