Three-way matching in AP automation

Buyer requirement: Automated three-way matching: PO to receipt to invoice with configurable tolerance (2% price, 5% quantity)

For a $250M technology company moving off email/Slack approvals and onto a structured P2P workflow, Stampli delivers full three-way matching across all three document legs: PO, goods receipt, and supplier invoice. When a vendor invoice arrives, Stampli's AI auto-detects that it is PO-backed and automatically performs line-level comparison of header, line, and footer data against the PO and against receipt data. Stampli automatically performs 2-way and 3-way matching of header, line-level, and footer PO data, and automatically skips invoice approvals if POs and invoices match, based on tolerances that you define. The tolerance settings cover price and quantity as distinct, customer-configured parameters: with automatic identification of exact matches and discrepancies, coupled with customer-defined tolerance settings, Stampli significantly reduces manual effort. Stampli's own documentation illustrates these as independent axes, for example allowing a quantity tolerance of +/- a unit count or percentage for one category while setting a separate price variance percentage for another. Stampli automatically skips invoice approvals if POs and invoices match, based on customer-defined tolerances; invoices outside those tolerances are flagged as exceptions and routed to reviewers with full PO, receipt, and invoice context side by side. For the receipt leg specifically, Stampli operates a receiving module for both native Stampli POs and ERP-originated POs, pushing receiving-confirmation notifications to the assigned Receiver proactively: timing is the difference between a clean match and a manual chase, and Stampli moves receipt confirmation earlier in the process; with receiving notifications, the assigned Receiver is prompted to confirm receipt earlier, so receipt status is captured ahead of matching and NetSuite stays the system of record for the item receipt. Receipt data already recorded in NetSuite is also synced in real time: Stampli does not replace NetSuite as the place where item receipts are recorded; receipts are entered in NetSuite, or through NetSuite receiving and WMS, and Stampli reads that receiving data to drive the match. Exceptions (missing receipts, out-of-tolerance price or quantity variances) are flagged and routed: missing-receipt invoices are flagged and routed with full PO, receipt, and invoice context.

Limitations: For this buyer's NetSuite environment, the authoritative item receipt record originates in NetSuite (or through Stampli's receiving notification workflow); a receiving team member must confirm receipt either in NetSuite or via Stampli's receiving module before the three-way match can fire, so the match is only as timely as the receiving confirmation. Published documentation confirms customer-defined price and quantity tolerances as distinct parameters, but the exact UI field names and whether each axis accepts a pure percentage (e.g., exactly 2.00% price / 5.00% quantity) versus only absolute-value thresholds should be verified with Stampli during a demo, as help-center articles describe the mechanism at a conceptual level rather than showing the specific configuration screen.

Buyer requirement: The system must support 3-way matching of purchase order, receipt confirmation, and invoice for goods and subcontractor-based transactions in construction, where receipt confirmation is captured as a project manager or superintendent contribution within the pre-processing workflow rather than assumed from a warehouse scan. 2-way matching that skips receipt confirmation is insufficient for a construction environment where work confirmation comes from field personnel, not a receiving dock.

For a multi-location construction company on NetSuite where work confirmation comes from project managers and superintendents rather than a receiving dock, Stampli's 3-way matching capability covers the mechanics of PO-receipt-invoice comparison but draws its receipt data from ERP-sourced records rather than from a field-personnel contribution step inside Stampli's pre-processing workflow. Stampli's AI 'connects POs, receipts, and invoices in real time' and performs both 2- and 3-way matching with configurable tolerance rules, partial-receipt processing, and line-level exception flagging. Its PO matching product page documents that the system can 'process invoices with full or partial receipts against a PO' with line-level adjustments, and the bi-directional NetSuite sync pulls live item receipt records from NetSuite for the match. The construction-specific content and the invoice verification documentation confirm that project managers can be included in the collaboration and communications loop on every invoice, and conditional approval routing can direct an invoice to a PM before payment. However, in Stampli's documented mechanism, the third leg of the 3-way match is a receipt record that already exists in NetSuite (entered by whoever creates item receipts in NetSuite, typically a warehouse or operations role), not a structured workflow step inside Stampli where a PM or superintendent provides the receipt confirmation themselves as a named contribution. A PM can ask questions, add comments, or be routed as an approver, but none of those actions formally supplies the receipt record that drives the match logic.

Limitations: The material ceiling for this buyer is that Stampli's 3-way match depends on a receipt record existing in NetSuite before matching runs; in a construction environment where no dock scan generates that record, a PM or superintendent would need to first enter an item receipt in NetSuite for the third leg of the match to exist, adding a step outside Stampli's workflow entirely. Stampli provides robust collaboration and approval routing to field personnel, but does not offer a native 'confirm work received' contribution step inside its own pre-processing flow that populates the receipt record and triggers the match.

Buyer requirement: The vendor must provide demonstrable evidence, through references or case studies from distribution or similarly PO-heavy industries, that their tool has closed a receiving gap comparable to the one described: organizations where employees were not recording receipts and three-way match was nonfunctional, and where the tool's proactive receipt confirmation workflow measurably increased receipt capture rates. This is a vendor evaluation criterion, not a configuration requirement, and is specifically scoped to operational procure-to-pay, excluding strategic sourcing, RFQ, or supplier onboarding capabilities.

This buyer needs documented proof that Stampli has already solved the specific problem of employees not recording goods receipts in distribution or comparably PO-heavy industries, with measurable receipt capture rate improvements as evidence. Stampli's product documentation confirms a relevant mechanism: Stampli AI connects POs, receipts, and invoices in real time, notifies teams when items are received or missing, and keeps ERP records in sync. The PO support page further documents that users can resolve discrepancies with tracked questions and responses and confirm receipt directly on the invoice processing page, with real-time PO data including receipt status surfaced directly in the platform. Stampli's in-app messaging layer also supports receipt confirmation prompts: AP teams can communicate efficiently with coworkers and vendors to clarify invoice details, confirm receipts, and resolve discrepancies, with all messaging consolidated into a single channel centered on each invoice. However, the specific evidentiary criterion the buyer requires (a published reference or case study from a distribution or PO-heavy company where the starting condition was broken receipt recording and the measured outcome was improved receipt capture rate) is not present in Stampli's public case study library. The closest available case study involves Superior Masonry, a construction company that saved $10,000 per month by improving invoice processing accuracy with Stampli, and Ollie, which automated invoice processing and PO matching with Stampli, reducing daily variance work from hours to minutes. Neither reference a distribution company, nor do they specifically frame the problem as broken employee receipt recording with a measured receipt capture rate outcome.

Limitations: Stampli's public case study library does not surface a distribution-industry or PO-heavy reference where the documented starting condition was nonfunctional three-way match due to employees not recording receipts and the documented outcome was a measurably higher receipt capture rate. The buyer evaluating this criterion will need to request distribution-specific references directly from Stampli's sales team, as the public evidence does not satisfy the specific proof requirement described.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a mid-market distributor whose three-way match today collapses because receiving records are never entered, Stampli's AI Line-Level PO Matching module addresses both the detection and disposition halves of this requirement. On the tolerance side, Stampli automatically performs 2-way and 3-way matching of header, line-level, and footer PO data, and automatically skips invoice approvals when POs and invoices match based on customer-defined tolerances. Admins configure percentage and dollar thresholds per their policies; invoices within those bands are auto-approved without human escalation, directly solving the noise problem the buyer describes. On the exception side, Stampli will automatically flag any discrepancies from matches and provide details directly next to the match in question, with all discrepancies and exceptions surfaced alongside the match. The system automatically identifies exact matches between header and line-level PO data, matches items with identical descriptions, quantities, rates, and amounts, and flags discrepancies when line items do not match. The invoice card functions as the shared workspace: Stampli AI performs line-level PO matching and surfaces and resolves exceptions in context before they create downstream cleanup; the invoice becomes the shared workspace for AP, approvers, and vendors, with questions, answers, supporting documents, and approvals all staying attached to the transaction. For routing exceptions to a defined handler rather than a generic queue, Stampli Procurement allows configuration of different approval requirements based on multiple variables, including different approval chains for capital versus operational expenses and dollar thresholds that trigger additional approval levels. Stampli's own best-practice guidance explicitly describes routing exceptions by invoice category to named roles, such as software invoice discrepancies to the IT Director and facility-related discrepancies to the Operations Manager, using the platform's configurable workflow rules.

Limitations: Stampli's product pages confirm discrepancy details are shown 'alongside the match' in a unified view, but publicly available documentation does not explicitly demonstrate a named system-level feature that keys exception routing to the variance TYPE (price vs. quantity vs. line-item) as a distinct routing criterion; the buyer should confirm during a demo that the approval workflow builder supports variance-type as a routing dimension, not only dollar amount or invoice category. Additionally, invoices are matched to purchase orders and receiving records and the system flags discrepancies for review before payment, meaning the receiving record must actually exist in the system for true three-way match exceptions to fire; this buyer's core receiving-gap problem (no one logs receipts) must be solved upstream before exception routing on three-way mismatches is possible.

Buyer requirement: The system must execute automated three-way match across the NetSuite PO, the goods receipt record captured via req_3, and the vendor invoice, without requiring manual reconciliation. Match results must be written back to NetSuite so that PO, receipt, and invoice line items are linked at the NetSuite record level, preserving audit lineage inside the ERP rather than only inside the procurement tool.

This distribution company currently has no goods receipt records in NetSuite, which means three-way match is structurally impossible today. Stampli closes that gap by operating as a Built-for-NetSuite certified SuiteApp that syncs open PO and receiving data from NetSuite continuously (every two hours or on-demand), pulling live item-receipt status directly into the AP workflow so AP teams never have to navigate away from Stampli to locate a receipt. Stampli AI (Billy the Bot) then performs automated three-way matching across the NetSuite PO, the goods receipt (item receipt record), and the vendor invoice at the line-item level, handling one-PO-to-many-invoice and many-PO-to-one-invoice scenarios as well as partial shipments. Match results, exceptions, and the linked PO-receipt-invoice relationships are written back to NetSuite via a bidirectional, token-authenticated integration: a sophisticated validation algorithm validates PO matching, inventory receipts, and invoice closing, and keeps NetSuite records in sync, preserving audit lineage at the NetSuite record level rather than only inside Stampli. Mismatches are automatically flagged and routed for exception handling without requiring manual reconciliation by AP staff.

Limitations: Stampli's three-way match depends on a goods receipt record already existing in NetSuite at the time of invoice processing; if this buyer's receiving gap persists upstream (i.e., warehouse staff still do not create item receipts in NetSuite), Stampli can flag the missing receipt but cannot itself create the NetSuite item receipt record on the requester's behalf. The buyer must solve the receipt-capture step (via req_3 proactive confirmation or another mechanism) to feed Stampli the receipt data it needs for a true three-way match.

Buyer requirement: The system must support two distinct matching regimes operating in parallel: 2-way matching (PO plus invoice, no receipt required) for service invoices, and full 3-way matching (PO plus goods receipt plus invoice) for inventory purchase orders. Each regime must support configurable tolerance rules and route exceptions to the appropriate reviewer without collapsing both invoice types into a single matching path.

For a 180-person services company on Sage Intacct needing simultaneous 2-way and 3-way matching across service invoices and inventory POs, Stampli operates at pre-processing stages 2 (PO match) and 4 (receipt confirmation) within a single platform. Stampli's PO Matching capability supports both 2-way and 3-way matching, handling complex scenarios such as blanket POs, multiple invoices, taxes, and freight charges. Stampli automatically performs 2-way and 3-way matching of header, line-level, and footer PO data, auto-detects PO-backed invoices with no manual rule creation required, and automatically flags any discrepancies or exceptions. Tolerance rules are configurable: with automatic identification of exact matches and discrepancies coupled with customer-defined tolerance settings, Stampli can automatically skip invoice approvals if POs and invoices match based on those defined tolerances. On the exception routing side, Stampli's Predefined Approval Workflows automatically assign invoices to the appropriate approvers based on predefined criteria including invoice amount, location, vendor, GL, and other fields, and conditional approval logic adjusts workflows based on request type, amount, department, or other criteria. However, no published documentation confirms that the system natively auto-selects the correct matching regime (2-way vs. 3-way) based on PO type or invoice category at ingestion, nor that tolerance rules can be scoped independently per matching regime rather than applied as a single global policy.

Limitations: The material ceiling for this buyer is that Stampli does not appear to offer a native, system-enforced dual-path matching engine that automatically routes service POs to a 2-way path and inventory POs to a 3-way path with regime-specific tolerance bands: the buyer would likely need to enforce this distinction through workflow configuration, Tray organization, or AP team process rather than a fully automated, per-regime classification at ingestion. The exception routing can be differentiated by invoice attributes (including custom fields), but whether that branching extends cleanly to separate tolerance thresholds per regime type is undocumented.

Buyer requirement: The solution must perform automated 3-way matching (PO line, goods receipt confirmation, and invoice line) for all 6,000 PO-based invoices processed monthly, with configurable quantity and price tolerance rules per vendor or PO type. This addresses pre-processing stages 2 and 4 directly, replacing the manual coordination currently required between the central AP team, the warehouse, and purchasing when quantities or prices do not align.

For a 10-person AP team processing 6,000 PO-based invoices monthly through SAP S/4HANA, Stampli's PO Matching module addresses pre-processing stages 2 (PO match) and 4 (receipt confirmation) directly within its AP layer. The SAP integration page documents 'live receiving status sync' that shows up-to-the-minute receipt quantities inside Stampli, and explicitly lists '2-way and 3-way matching leveraging SAP receiving data for straight-through processing' as a named capability. The integration covers one PO to multiple invoices (and vice versa), handling partial receipts and cross-department orders, with a live receiving status sync that shows up-to-the-minute receipt quantities inside Stampli. At the line level, Stampli automatically performs 2-way and 3-way matching of header, line-level, and footer PO data, automatically identifying exact matches and flagging discrepancies when line items do not match. GR data flows passively from SAP via a bi-directional bridge: Stampli syncs POs, vendors, and master data every 2 hours, with critical matching data available in real time; document posting happens every 5 minutes; and PO line-level data including receiving status is always current so AP teams never work with stale information when matching invoices. Invoices that pass tolerance checks skip the approval queue entirely: Stampli automatically skips invoice approvals if POs and invoices match, based on customer-defined tolerances. For exceptions, Stampli automatically flags any discrepancies or exceptions with details provided alongside the match, and users can easily send messages across departments or to vendor contacts without leaving the PO-matching workspace, replacing the email-and-phone coordination currently required between AP, the warehouse, and purchasing. The SAP S/4HANA integration is handled through a pre-built on-premises connector: Stampli's pre-built SAP integrations can be implemented in days, not weeks, with no changes to SAP or business processes, and Stampli supports true 2- and 3-way matching with SAP, including the ability to access live PO data to ensure invoices are matched to the most up-to-date information.

Limitations: Tolerance configuration is consistently documented as 'customer-defined' at the organization level, with examples showing global percentage and dollar thresholds; no Stampli source explicitly confirms per-vendor or per-PO-type tolerance rule granularity, which the buyer's requirement specifies. This should be confirmed during a demo or scoping call, particularly for vendor relationships with materially different acceptable variance bands.

Buyer requirement: When a 3-way match fails on any of the 6,000 PO-based invoices, the system must automatically route the exception to the correct resolver (warehouse for receipt discrepancies, purchasing for price or terms discrepancies) with the full PO line, receipt record, and invoice line presented side by side in the exception task. Exception routing must support escalation on timeout and reroute when the assigned resolver is unavailable, so that the central AP team does not need to manually chase resolution as they currently do.

For a buyer running 6,000 PO-based invoices monthly against SAP S/4HANA, Stampli covers the core matching and escalation mechanics but falls short on the specific discrepancy-type-aware routing the buyer requires. On the matching side, Stampli's SAP integration supports both 2-way and 3-way matching, leverages SAP receiving data for straight-through processing, and maintains a live receiving status sync that shows up-to-the-minute receipt quantities inside Stampli, meaning GR data from MIGO is pulled into the Stampli exception context in real time rather than requiring a resolver to open a second SAP screen. The integration must seamlessly sync real-time invoice, PO, and receipt data with SAP and handle approval workflows, and Stampli AI performs line-level PO matching and surfaces and resolves exceptions in context. On the exception workspace, Stampli offers a superior user interface for line-level adjustments that supports both 2-way and 3-way matching; its intuitive interface eliminates dragging and dropping and provides a single view for matched and unmatched items, with automatic identification of exact matches and discrepancies plus customer-defined tolerance settings. For routing to non-AP resolvers, AP Assignments allows organizations to automatically route invoices to the right users based on specific invoice characteristics such as business unit, region, office, department, vendor, or any other custom criteria; and trays route invoices to the right teams automatically, dynamic approval workflows adapt to your approval logic, and role-based visibility keeps access tight. On escalation and OOO handling, fallback routing automatically redirects purchase requests to designated backup approvers when primary approvers are unavailable; approvers can designate temporary substitutes for specific date ranges; authorized users can reassign pending approvals without disrupting the entire process; and configurable escalation rules can automatically route requests to alternative approvers if they remain pending for too long. The material gap: Stampli's routing logic is keyed to invoice attributes (vendor, department, custom fields) configured at setup. There is no documented mechanism by which the system classifies the type of match failure — quantity/receipt discrepancy versus price/terms discrepancy — and automatically routes to a different resolver role based on that classification. Billy matches invoice details against the PO and flags discrepancies for the AP team to investigate, but the documented path after flagging routes to AP or to configurable approvers, not to a warehouse or purchasing role selected automatically by exception type. The buyer's described pattern (receipt discrepancy auto-routes to warehouse, price discrepancy auto-routes to purchasing) would require pre-configured assignment rules using custom fields or manual AP reassignment, which replicates some of the manual chasing the buyer wants to eliminate.

Limitations: Stampli does not document automatic discrepancy-type classification (receipt gap versus price/terms variance) that drives resolver routing to warehouse versus purchasing without AP intervention; the buyer would need to configure separate assignment paths using custom invoice attributes as a proxy, which requires exception type to be surfaced as a field before routing fires. Additionally, the exception task view presents contextual data on the invoice but is not explicitly documented as a structured side-by-side three-column workspace (PO line, GR record, invoice line simultaneously) designed for non-AP resolvers who lack SAP access.

Buyer requirement: For PO-backed invoices (expected as standard in a mid-market manufacturing operation), the system must perform 3-way matching: purchase order lines, goods receipt or warehouse confirmation, and invoice lines, with configurable tolerance rules and automatic exception routing when a mismatch is detected. 2-way matching that bypasses receipt confirmation (stage 4 of the pre-processing journey) is insufficient for a manufacturing environment where physical receipt of goods is a distinct event.

For a mid-market manufacturer running 1,200 invoices per month on Sage Intacct, Stampli's PO Matching module directly addresses all five components of this requirement. On receipt data ingestion (the critical stage 4 question): Stampli's Sage Intacct integration syncs live PO receipts, lines, and status every two hours or on demand, making goods receipt confirmation a system-driven checkpoint rather than a manual lookup. Stampli auto-syncs PO and receipts data with Sage Intacct and performs three-way matching of POs to invoices, including partial amounts and multiple-PO-to-single-invoice scenarios. On line-level matching depth: Stampli's PO Matching capability supports both 2-way and 3-way matching, handling complex scenarios such as blanket POs, multiple invoices, taxes, and freight charges. Stampli automatically identifies exact matches between header and line-level PO data, matches items with identical descriptions, quantities, rates, and amounts, and flags discrepancies when line items do not match. Billy, Stampli's AI, extends this further: Billy codes invoices line by line and links invoices to the right POs or receipts, all before anyone lifts a finger. On configurable tolerance rules: Stampli applies customer-defined tolerance settings with automatic identification of exact matches and discrepancies, and its bi-directional ERP sync ensures real-time data accuracy. Stampli automatically skips invoice approvals if POs and invoices match based on customer-defined tolerances. On exception routing: Stampli supports developing processes for managing matching exceptions and creating workflows to route exceptions to the appropriate approver, for example routing facility-related discrepancies to the Operations Manager. The Help Center confirms the end-to-end loop: invoices are matched to purchase orders and receiving records, and the system flags discrepancies so they can be reviewed before payment.

Limitations: The Sage Intacct receipt sync cadence is documented at up to two hours (with an on-demand refresh option), meaning a goods receipt recorded in Intacct minutes before invoice processing may not yet be visible in Stampli without a manual refresh; this is a minor operational timing consideration in a high-velocity receiving environment, not a capability gap. No evidence was found that the tolerance rules can be configured per individual line item versus per invoice, which is worth confirming in a proof-of-concept for a manufacturing buyer with mixed line criticality.

Buyer requirement: The system must perform AI-assisted 3-way matching across all three document legs: the SAP S/4HANA purchase order (line by line), the SAP goods receipt (GR) document confirming physical inventory receipt, and the supplier invoice. For the approximately 2,450 PO-based invoices processed each month (70% of 3,500), matching must operate at the line-item level, not just header totals, and must apply configurable quantity and price tolerance rules to distinguish auto-approvable variances from true exceptions requiring human review.

For a manufacturing company running 3,500 invoices per month with 70% PO-based volume against SAP S/4HANA, Stampli addresses this requirement through its purpose-built SAP integration and PO Matching module. On the data-plumbing side, a bidirectional, real-time connector syncs PO line-level data (item, rate, quantity, description) and live goods receipt (GR) quantities from SAP S/4HANA into Stampli continuously, with PO and GR data refreshed in near real time and document postings pushed every five minutes, so AP never works against stale receiving data. The matching engine then operates at the line-item level: it automatically identifies exact matches across header and line-level PO data, matches items by description, quantity, rate, and amount, and flags discrepancies when line items deviate, covering all three document legs: the SAP PO, the SAP GR, and the supplier invoice. Billy (Stampli's AI) connects POs, receipts, and invoices in real time, performing 2- and 3-way matching, and automatically skips approval routing when POs and invoices match within customer-defined tolerances, routing only true exceptions to human reviewers. Tolerance rules are configurable: buyers can set percentage-based price and quantity variance thresholds, and can further condition them by vendor or invoice value band, so the roughly 2,450 PO-based invoices per month can be bucketed into auto-approvable matches and flagged exceptions without manual triage. This covers pre-processing stages 2 (PO match) and 4 (receipt confirmation via SAP GR data) of the five-stage journey, with stage 5 (cost allocation) handled via Stampli's line-level GL coding and Billy's AI-driven dimension suggestions.

Limitations: Stampli's documented tolerance configuration is described at the customer-defined rule level; published documentation does not detail whether tolerance bands can be set independently per PO line category or material group within a single SAP company code, which may matter for a manufacturer with heterogeneous inventory categories carrying different acceptable variance ranges. Additionally, while GR data flows from SAP in near real time, the goods receipt itself must still be posted in SAP's MM module by warehouse staff before Stampli can complete the 3-way match; Stampli does not replace or replicate SAP's MIGO/GR posting step.

Buyer requirement: Exception routing must be driven by the specific reason a 3-way match fails, not by a generic 'exception' flag. Price discrepancies must route to the procurement or contract owner who holds the agreed terms; quantity discrepancies must route to the warehouse or receiving team who can confirm or correct the GR; invoice legitimacy questions must route to the AP team. This separation is essential because the buyer's 5-person team is currently absorbing all exception types indiscriminately, which is the primary productivity bottleneck at the receipt confirmation and terms verification stages of the pre-processing journey.

For a manufacturer processing 3,500 invoices per month with 70% PO-based and a high exception volume, Stampli's 3-way matching is real and well-documented: Billy connects POs, receipts, and invoices in real time, performs 2- and 3-way matching, notifies teams when items are received or missing, and keeps ERP records in sync. When a match fails, the system flags discrepancies so they can be reviewed before payment. Stampli then offers two routing architectures to handle flagged invoices: Predefined Approval Workflows, which create and maintain fixed workflows based on invoice field criteria, assigning specific approvers based on up to 5 invoice field values such as vendor, company, amount, and department; and Trays, which excel at managing incomplete or exceptional documents through specialized routing, allowing dedicated workspaces for documents missing specific requirements, ensuring they do not proceed to approval until properly prepared. The critical limitation for this buyer is that both mechanisms are driven by invoice-level field attributes (vendor, amount, GL, department), not by the reason a 3-way match failed. Stampli's own documentation of exception handling describes a single destination: if documents do not match, Billy flags the discrepancy for the AP team to investigate, which replicates the buyer's exact current bottleneck rather than decomposing it. There is no documented native mechanism by which a price variance (stage 3: terms verification) auto-routes to the procurement or contract owner, while a quantity variance (stage 4: receipt confirmation) auto-routes to the warehouse or receiving team, as two structurally separate paths triggered by the match-failure reason code itself. Billy identifies approvers automatically using historical patterns, invoice data, and approval logic built around the company's policies, but this AI-driven routing learns from invoice attributes and past approval history, not from a classified exception type (price vs. quantity vs. legitimacy) as the primary branching variable.

Limitations: Stampli's routing configurability (Predefined Workflows, Trays, dynamic AI routing) is built on invoice-field criteria such as vendor, amount, department, and GL, not on match-failure reason codes. Achieving the buyer's required disaggregation of price discrepancies to procurement and quantity discrepancies to receiving would require engineering custom yes/no or drop-down fields that Billy or a workflow populates upon match failure, then using those fields as Tray or Predefined Workflow triggers; this is a workaround configuration, not a documented out-of-box capability, and it introduces implementation risk and ongoing maintenance overhead that may not fully survive edge cases at 3,500 invoices per month.

Buyer requirement: For the roughly 1,050 non-PO invoices processed each month (the remaining 30% of 3,500), the system must support AI-assisted GL coding and cost allocation routing to the appropriate budget owner for approval, since these invoices do not have a PO or GR document to anchor a 3-way match. The coding model must suggest SAP cost objects (cost center, GL account, plant) based on vendor history and invoice content, and must route to the correct budget owner based on the suggested cost allocation rather than defaulting to a fixed AP-team approval chain.

For this manufacturer's approximately 1,050 non-PO invoices per month, Stampli's Billy AI handles all five pre-processing stages without requiring a PO anchor. When a non-PO invoice arrives, Billy detects that the invoice is not associated with a purchase order and automatically identifies the cost center and expense type, then codes the invoice in Stampli. The coding model draws on learned history: Billy reads the header, line items, tax amounts, and even freight splits, then proposes coding based on historical patterns. For the SAP cost object fields this buyer requires, Stampli's SAP S/4HANA integration syncs WBS elements, cost centers, and project codes alongside standard GL and PO data, so Billy's suggestions are drawn from live SAP master data, not a flat list. For recurring non-PO vendors, templates can be tailored to specific vendors for consistent coding, and the system provides context-aware template selection so coders only see templates relevant to the invoice they are working on. On the approval side, the routing is explicitly dynamic and cost-object-aware: drag-and-drop conditions, including amount, cost center, and project stage, define who needs to sign off on requests, and Stampli provides a choice between fixed and dynamic workflows, where dynamic workflows use ML technology to learn cost accounting and approval processes and automatically sense and adapt when business rules change, with no IT rework needed. The approver resolution is not a fixed AP-team chain: Billy identifies approvers automatically using historical patterns, invoice data, and approval logic built around the company's policies, routing every invoice to the right people and keeping the process on track. The SAP integration is a pre-built bridge connector that syncs bi-directionally every few minutes, keeping systems aligned across purchase orders, receiving details, vendor information, general ledgers, cost centers, item categories, custom fields, and invoice specifics.

Limitations: Billy's approver resolution for non-PO invoices is ML-learned from historical patterns rather than a rules-configured cost-center-to-budget-owner lookup table, meaning routing accuracy for infrequent or brand-new cost center and vendor combinations will be lower early in deployment and will require AP-team review until Billy accumulates sufficient signal. There is no documented hard-coded mapping interface where an admin can explicitly define cost center X routes to budget owner Y without relying on pattern learning.

Buyer requirement: Automated three-way matching: PO to receipt to invoice with configurable tolerance (2% price, 5% quantity)

For this $250M technology company moving from email-based approvals to a formal P2P workflow, Stampli's PO Matching module covers the full three-way match chain: PO, goods receipt (receiving records), and vendor invoice. Invoices are matched to purchase orders and receiving records, and the system flags discrepancies so they can be reviewed before payment. The matching engine operates at the line level, not just header totals: it automatically identifies exact matches between header and line-level PO data, matches items with identical descriptions, quantities, rates, and amounts, and flags discrepancies when line items do not match. On the tolerance side, with automatic identification of exact matches and discrepancies coupled with customer-defined tolerance settings, Stampli significantly reduces manual effort and automatically skips invoice approvals if POs and invoices match based on those tolerances. Exceptions route to a human review queue: Stampli's embedded AI automates matching purchase orders to invoices and routing approvals, allowing finance teams to focus on reviewing exceptions and making informed decisions. The mechanism is confirmed through stage 4 of the pre-processing journey (receipt confirmation is included), not just stage 2 (PO-to-invoice only): Stampli can process invoices with full or partial receipts against a PO, and is highly flexible in accommodating various invoice scenarios. However, while tolerance is confirmed as customer-defined, available documentation does not confirm that price tolerance and quantity tolerance are independently configurable as separate parameters (e.g., 2% for price and 5% for quantity as distinct thresholds), nor is per-category tolerance configuration (IT vs. facilities vs. professional services) documented in public sources.

Limitations: The buyer requires two independently configurable tolerance thresholds (2% price, 5% quantity as separate parameters); Stampli's public product documentation confirms 'customer-defined tolerances' but does not specify whether price and quantity tolerances are set independently or whether tolerances can be configured per purchase category rather than globally, which is a material ceiling for this buyer's mixed-category spend across IT, facilities, professional services, and direct materials.

Buyer requirement: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For a real estate portfolio running 8 entities, Stampli's PO Matching module performs 3-way matching (PO plus receipt plus invoice) natively at the line-item level, including header, line-level, and footer PO data, covering stage 2 (PO terms verification) as a primary function. Stampli automatically performs 2-way and 3-way matching of header, line-level, and footer PO data, with automatic flagging of discrepancies when line items do not match and the ability to skip approvals if POs and invoices match based on customer-defined tolerances. Billy the Bot auto-detects PO-backed invoices without manual rule creation, then automatically flags any discrepancies or exceptions with details provided alongside the match, and automatically skips invoice approvals if POs and invoices match based on customer-defined tolerances. For stage 4 receipt confirmation, Billy connects POs, receipts, and invoices in real time, performs 2- and 3-way matching, notifies teams when items are received or missing, and keeps ERP records in sync via bi-directional NetSuite sync: the receipt confirmation data flows from NetSuite item receipts into Stampli's matching engine rather than from a standalone receipt acknowledgment gate inside Stampli itself. On exception detection, if documents match, the invoice is forwarded for approval; if they do not match, the discrepancy is flagged for the AP team to investigate, then routed to the appropriate approver or approvers. Multi-entity scale is confirmed: AI-powered AP platforms learn entity-specific patterns and apply the correct coding, routing, and matching rules automatically, with Stampli supporting 2,700+ entities across 1,800+ customers, trained on the full range of multi-entity configurations.

Limitations: The material ceiling for this buyer is twofold. First, stage 4 receipt confirmation is not a native, standalone gate inside Stampli: it depends on NetSuite item receipt records existing before matching runs, which means the quality of the 3-way match for construction and vendor work order invoices (which are service-based rather than goods-based) relies on the buyer's field team or project managers creating GRN or completion records in NetSuite. Stampli's own documentation notes that service suppliers do not usually send shipping receipts because they are not delivering products, and that three-way matching is typically not used for services. Second, publicly documented tolerance configuration is described as 'customer-defined' at the account level; there is no explicit documentation confirming that tolerance thresholds can be set distinctly per each of the 8 entities rather than applied globally, which limits the buyer's ability to enforce stricter controls on high-risk commercial construction entities versus residential entities.

Buyer requirement: The system must perform true 3-way matching at the line-item level, reconciling each invoice line against the originating NetSuite purchase order and the corresponding item receipt before the invoice advances to approval. Discrepancy thresholds (quantity and price tolerances) must be configurable per entity so that match failures trigger automatic exception routing rather than silently passing through.

For a NetSuite mid-market buyer processing 1,500 invoices per month across multiple entities, Stampli pulls live NetSuite PO and item receipt data into its AP workspace, refreshing every two hours or on demand. Stampli supports true 3-way matching at the item receipt level, with live PO and receiving data refreshing every two hours (or on demand), enabling validation against actual received quantities rather than just PO headers. Live PO, receipt, and item receipt data flow into Stampli, enabling true 3-way matching, split PO scenarios, and rapid exception handling — all within the AP application; the feature set explicitly includes true 2-way and 3-way matching to item receipts, live receiving status and PO sync, and PO header data auto-mapped to invoices. On discrepancy detection, invoices are matched to purchase orders and receiving records, and the system flags discrepancies so they can be reviewed before payment. Stampli's dynamic workflows let users add approvers on the fly and handle exceptions without rebuilding rules. However, no Stampli help center or product documentation found across multiple targeted searches describes configurable quantity or price tolerance thresholds — the parameters a buyer would set to define what deviation triggers an exception vs. passes silently — and no per-entity or per-subsidiary tolerance profiles are documented anywhere in Stampli's published materials. The flagging behavior appears binary (discrepancy detected equals flag) rather than threshold-governed, which is a material ceiling for this buyer's requirement of distinct configurable tolerances per entity.

Limitations: The critical gap for this buyer is the absence of documented configurable tolerance thresholds (quantity variance %, price variance %) and the complete absence of per-entity tolerance profiles: Stampli flags discrepancies as a binary condition rather than exposing a tolerance engine the buyer can calibrate differently per subsidiary. A Tipalti competitive page explicitly positions its own 'flexible matching tolerance engine' configurable at the header or line level as a differentiator, further indicating Stampli does not surface this capability in its standard product documentation.

Buyer requirement: Exception routing for 3-way match failures must feed into a configurable approval workflow that presents approvers with the specific discrepancy details (PO line, receipt line, and invoice line side by side) and routes to the correct entity-specific approver role based on the invoice's subsidiary, cost center, and dollar threshold. Approval chains must support parallel and sequential routing without requiring IT intervention to modify.

For a 1,500-invoice-per-month NetSuite OneWorld environment, Stampli's workflow engine handles the full exception-to-approval chain as follows. When a 3-way match fails, live PO, receipt, and item-receipt data flow into Stampli every few minutes, enabling true three-way matching, split PO scenarios, and rapid exception handling — all within the AP application, so approvers do not need to navigate back into NetSuite to see match data. Billy the Bot performs line-level PO matching and surfaces and resolves exceptions in context — before they create downstream cleanup. Routing from those exceptions feeds into a configurable approval engine: Stampli provides highly configurable approval workflows that can set up approval chains based on department, dollar amount, category, vendor, or any combination of these factors, and the system accommodates multiple approval stages, parallel approvals, delegate approvers for vacations, and escalation processes to ensure nothing gets stuck in the workflow. Subsidiary-level isolation is handled natively: fixed approval workflows require no IT — finance builds and maintains structured flows directly in Stampli, and with built-in OneWorld support, Stampli lets businesses manage multiple subsidiaries from a single Stampli account. Routing dimensions include cost center and subsidiary: the intuitive workflow builder allows configuring approval sequences visually, defining routing rules based on attributes like department, cost center, or spending threshold. The key limitation for this buyer is the side-by-side discrepancy display: while Stampli confirms line-level PO and receipt data is present in the approver interface, no documentation explicitly describes a structured three-column panel placing PO line, receipt line, and invoice line in a formal side-by-side comparison view — the discrepancy context is surfaced via the activity feed and line-level fields rather than a dedicated discrepancy comparison UI.

Limitations: The buyer's requirement for a formal side-by-side PO line / receipt line / invoice line discrepancy panel in the approver view is not explicitly documented; Stampli surfaces line-level exception context within its collaborative invoice interface but whether this constitutes a structured three-column comparison layout (vs. contextual line-level data) is unconfirmed and would need direct product demonstration. Additionally, while parallel approvals are documented at the PO workflow level, the explicit confirmation of true parallel gating (all parallel approvers must act before the chain advances, as opposed to CC-style notification) on AP invoice approval chains specifically should be validated during a demo.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a multi-location services company running 1,800 invoices per month across two Sage Intacct entities, Tipalti's PO Matching module covers pre-processing stages 2 through 4: PO-line comparison, tolerance evaluation, and goods receipt confirmation. When a PO-based invoice arrives, Tipalti pulls POs and goods receipt records (PO receivers) directly from Sage Intacct and compares invoice line items against both documents. Tolerances are configured by the buyer as either a dollar amount or a percentage at the bill level or the individual line level, meaning the buyer's specific 2% price and 5% quantity thresholds can be set exactly as required. If all line variances fall within those thresholds, the invoice auto-approves and a vendor invoice record is synced back to Intacct with a linked bill created automatically; if any line exceeds the threshold, Tipalti flags the invoice and routes exceptions to a designated reviewer via an email-based approval workflow, where the approver can approve or contest with a single click without logging into the platform.

Limitations: The Sage Intacct help documentation notes that syncing bills to Intacct before approval is not available for payers using the PO Matching feature, which means approved bills will post to Intacct only after matching and approval complete in Tipalti rather than earlier in the cycle. For the buyer's 45% non-PO invoice volume (utilities, subscriptions, professional services), 3-way matching does not apply and those invoices follow a separate GL-coding and approval path without receipt confirmation.

Buyer requirement: The system must support 3-way matching of purchase order, receipt confirmation, and invoice for goods and subcontractor-based transactions in construction, where receipt confirmation is captured as a project manager or superintendent contribution within the pre-processing workflow rather than assumed from a warehouse scan. 2-way matching that skips receipt confirmation is insufficient for a construction environment where work confirmation comes from field personnel, not a receiving dock.

For this multi-location construction company running Oracle NetSuite, Tipalti's PO Matching module does support 3-way matching of purchase order, receipt (GRN), and invoice, covering stages 2 and 4 of the pre-processing journey. The fact sheet's supporting tier explicitly commits to "2 and 3-way PO matching", and Tipalti's help documentation confirms the mechanism: "the process of matching goods and services from purchase orders to invoices (2-way matching), and receipts (3-way matching)" is supported in the PO Matching module. For the NetSuite integration specifically, "if you are using receipts as part of the PO Matching feature, an 'Item receipts' field displays" and the direction is configured as "NetSuite to Tipalti", meaning GRNs (goods received notes) are synced from NetSuite into Tipalti as the receipt leg of the 3-way match. GRNs can also be loaded via CSV file import: "Purchase orders imports data for all purchase orders that were created and/or updated" and "GRNs imports data for all receipts (GRNs) that were created and/or updated." The material ceiling for this construction buyer is that GRN creation does not happen as a direct in-workflow contribution by a field user inside Tipalti. A project manager or superintendent cannot originate a receipt confirmation within Tipalti's AP pre-processing workflow; the GRN must first be entered as an item receipt in NetSuite (or imported via CSV), then synced to Tipalti, before 3-way matching can proceed. That architecture requires the PM or superintendent to be a NetSuite user, not a Tipalti contributor, which contradicts the buyer's stated need for field personnel to contribute work confirmation within the AP pre-processing flow without logging into the ERP. Bill approvers can approve via email without logging into the Tipalti Hub, but that covers the approval step, not the receipt-creation step required by 3-way matching.

Limitations: Receipt confirmation (stage 4 of the pre-processing journey) depends on a GRN record already existing in NetSuite or being submitted via CSV import before matching occurs; Tipalti provides no documented mechanism for a construction PM or superintendent to originate a work-completion confirmation directly inside Tipalti's invoice workflow, which is the buyer's explicit requirement for field-sourced receipt confirmation. This means the buyer's PMs and superintendents would need NetSuite access or a parallel CSV import process to create GRN records, adding operational complexity that defeats the low-friction contribution model the buyer needs.

Buyer requirement: The vendor must provide demonstrable evidence, through references or case studies from distribution or similarly PO-heavy industries, that their tool has closed a receiving gap comparable to the one described: organizations where employees were not recording receipts and three-way match was nonfunctional, and where the tool's proactive receipt confirmation workflow measurably increased receipt capture rates. This is a vendor evaluation criterion, not a configuration requirement, and is specifically scoped to operational procure-to-pay, excluding strategic sourcing, RFQ, or supplier onboarding capabilities.

The buyer's problem is precisely that employees never returned to the system to log goods received, leaving three-way match non-functional. Tipalti does document a proactive receipt capture mechanism in its PO Management module: requesters are prompted to log goods received directly in Tipalti or via email at the right moment, with item statuses automatically updated to facilitate three-way PO match. However, the specific evaluation criterion here is not whether the mechanism exists but whether Tipalti can present demonstrable evidence from distribution or PO-heavy industries that this proactive prompt measurably closed a receiving gap comparable to the buyer's. Across Tipalti's entire public case study library, the named customers are concentrated in digital-first verticals: digital advertising (PubMatic), streaming (TuneIn), education (Skillshare), wine marketplace (Vivino), registry/e-commerce (Zola), consumer electronics (JLab), and marketing (Brooklinen). None of these case studies surface receipt-capture rate improvement as an outcome, and none are set in distribution, wholesale, or a comparably PO-heavy physical-goods environment.

Limitations: Tipalti's published reference base skews overwhelmingly toward SaaS, adtech, and creator-economy customers whose AP challenge centers on mass payments and tax compliance, not goods receipt capture in high-PO-volume physical distribution. A distribution buyer evaluating this criterion will find no publicly available proof point that the proactive receipt prompt has moved the needle on receipt capture rates in an environment like theirs.

Buyer requirement: The system must execute automated three-way match across the NetSuite PO, the goods receipt record captured via req_3, and the vendor invoice, without requiring manual reconciliation. Match results must be written back to NetSuite so that PO, receipt, and invoice line items are linked at the NetSuite record level, preserving audit lineage inside the ERP rather than only inside the procurement tool.

This buyer's core problem is a broken receiving chain: POs exist in NetSuite but no item receipts are created, so three-way match cannot close. Tipalti's PO Matching module explicitly supports both 2-way and 3-way matching, with 3-way defined in Tipalti's own help center as matching invoices against POs and receipts. For the NetSuite integration, the setup documentation shows that item receipts are configured to sync in the 'NetSuite to Tipalti' direction only: Tipalti pulls existing item receipt records from NetSuite into its matching engine rather than generating new receipt records back in NetSuite. This means the 3-way match computation runs inside Tipalti, and once a bill is fully matched and approved, it syncs to NetSuite as a bill entry. The approved bill does carry PO linkage because PO lines marked 'Closed' in NetSuite are tracked through the sync, and bill attachments can be synced. However, the documentation does not confirm that the NetSuite bill record is natively linked to the specific item receipt record at the NetSuite transaction level, which is what this buyer needs to preserve full audit lineage inside the ERP rather than only inside Tipalti.

Limitations: The item receipt sync flows only from NetSuite to Tipalti, so Tipalti's 3-way match depends on receipt records already existing in NetSuite — which is precisely the gap this buyer is trying to close. If Tipalti Procurement's receipt-confirmation step (triggered by the requester) creates the receipt record only inside Tipalti and does not write a corresponding item receipt back to NetSuite, the three-way linkage at the NetSuite record level (PO + item receipt + bill linked together) will be incomplete, meaning the audit trail lives in Tipalti rather than inside the ERP.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a distribution company on NetSuite whose three-way match is broken, Tipalti's PO Matching module addresses the tolerance and routing requirement in meaningful but incomplete ways. On tolerance, administrators can create tolerance thresholds based on amounts or percentages at the bill or line level, so invoices are still considered matched if they are within the threshold; discrepancies in quantity, price, or value that fall within the set tolerance range result in automatic approval without manual intervention, while those that exceed the range are flagged for further review. On exception routing, Tipalti's matching exception console streamlines exception reconciliation by enabling the user to view PO and bill lines side-by-side and drag-and-drop line items; and customizable exception rules route invoices that cannot be auto-matched based on the established tolerance ranges to ensure fast approvals. The product page documents clear highlights of exceptions, where they occur, and steps to resolve them, along with the ability to configure exception approval rules so the buyer can approve or reject directly via email. However, the documented side-by-side console covers PO and bill lines; explicit evidence of a simultaneous three-document view (PO line vs. goods-receipt line vs. invoice line in a single pane showing which of the three diverges) is absent from available documentation, as is evidence of tiered escalation logic that routes small variances to an AP clerk, larger variances to a procurement manager, and the largest to a CFO based on dollar thresholds.

Limitations: The material ceiling for this buyer is the exception context depth: Tipalti documents configurable tolerance thresholds and email-based exception approval routing, but the documented matching exception console appears to compare PO and bill lines rather than presenting all three documents (PO, GRN, invoice) simultaneously with per-document delta attribution; there is also no documented evidence of tiered role-escalation by variance magnitude, meaning large and small exceptions may route through the same handler path rather than auto-escalating up the authority chain.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

This buyer processes roughly 990 PO-based invoices per month across facilities, supplies, and subcontractors: exactly the goods-and-services mix where 3-way matching is the control standard. Tipalti's PO Matching module covers all three stages of the pre-processing journey for PO invoices: PO match (stage 2), receipt confirmation (stage 4 via Goods Receipt Note capture inside Tipalti), and exception routing (stage 5 escalation). The mechanism works as follows: when an invoice arrives, the system automatically compares it against the corresponding PO and GRN at the line-item level, checking quantity, price, and description; if discrepancies fall within the configured tolerance thresholds, the invoice auto-approves without manual intervention; if they exceed the threshold, the invoice is flagged and a workflow is triggered for manual resolution. Tolerance configuration is explicit and buyer-controlled: the buyer can set thresholds by amount or percentage at either the bill level or the line level, which directly maps to the buyer's stated requirement of 2% price and 5% quantity tolerances. For goods receipt, Tipalti captures the GRN natively: requesters are prompted to log goods received directly in Tipalti or via email at the right moment, with item statuses automatically updated to enable the 3-way match. Exception handling includes color-coded exception visibility, configurable exception approval rules, and the ability for approvers to approve or reject directly via email without logging in.

Limitations: One real-world note from third-party analysis is that Tipalti's procurement and AP modules can operate somewhat independently, meaning GRN logging discipline by receiving staff is critical: a GRN entered late creates a timing mismatch that generates false exceptions and erodes straight-through processing rates. The buyer should verify during implementation that Sage Intacct receipt records sync bidirectionally to Tipalti in real time, as at least one user has reported that PO updates made in the ERP after an invoice is already matched in Tipalti can require manual intervention to post correctly.

Buyer requirement: The system must support two distinct matching regimes operating in parallel: 2-way matching (PO plus invoice, no receipt required) for service invoices, and full 3-way matching (PO plus goods receipt plus invoice) for inventory purchase orders. Each regime must support configurable tolerance rules and route exceptions to the appropriate reviewer without collapsing both invoice types into a single matching path.

For a 180-person services company mixing service POs and inventory POs, Tipalti's PO Matching module supports both matching types within a single platform. The fact sheet commits to both modes: 'Ensure accuracy and prevent fraud with 2 and 3-way PO matching.' On the mechanism side, Tipalti AP automation software automates 3-way matching of invoices to purchase orders (POs) and goods received notes (GRNs) and handles applicable 2-way matching. Critically, a GRN isn't necessary if the type of purchase doesn't require a GRN because the invoice line items don't need to be received (instead, use 2-way matching of the invoice only to the PO). Tolerance configuration exists at granular levels: rather than manually reviewing all mismatches between invoices, purchase orders, and receiving reports, you can create tolerance thresholds based on amounts or percentages and the bill or line level, so an invoice is still considered 'matched' if it's within the threshold. Exception routing is also configurable: configurable rules align with company matching policies by dollar amount or supplier account, and customizable exception rules route invoices that cannot be auto-matched based on established tolerance ranges to ensure fast approvals. The Tipalti help center navigation confirms discrete configuration sections for 'Matching process,' 'Handle matching exceptions,' 'Bill routing,' and 'Matching policies' as separate areas within the PO Matching module. Tipalti's invoice management page documents 'configurable rules for two-way and three-way matching at both header and line-item levels,' and the ability to 'handle mismatches with tolerance ranges and set up exception approvals to resolve unmatched invoices efficiently.' The gap for this buyer is at the regime-selection layer: no publicly available documentation confirms that Tipalti automatically classifies an incoming invoice as a service PO (triggering 2-way) versus an inventory PO (triggering 3-way) based on a PO type or category attribute at ingestion, without a human making that routing decision. The configurable rules appear to branch on dollar amount and supplier account, not explicitly on a PO commodity or line-type tag. This means the buyer's requirement for two regimes operating in parallel without collapsing into a single path may require manual classification of PO type at setup, or rely on supplier-level policy assignment rather than invoice-type-level branching at runtime.

Limitations: The critical unconfirmed mechanism is automated regime selection: Tipalti's documented routing dimensions are dollar amount and supplier account, not PO category (service vs. inventory), so the buyer cannot confirm that service POs will automatically enter the 2-way path and inventory POs the 3-way path without manual classification or workaround configuration. Additionally, the separate exception reviewer queues per match type (a 2-way discrepancy to one reviewer, a 3-way goods-receipt variance to a different receiving-dock reviewer) are not explicitly documented as branching on match type itself, only on threshold and approval rules.

Buyer requirement: The solution must perform automated 3-way matching (PO line, goods receipt confirmation, and invoice line) for all 6,000 PO-based invoices processed monthly, with configurable quantity and price tolerance rules per vendor or PO type. This addresses pre-processing stages 2 and 4 directly, replacing the manual coordination currently required between the central AP team, the warehouse, and purchasing when quantities or prices do not align.

For a buyer running 6,000 PO-based invoices monthly with a central AP team coordinating with a warehouse and purchasing on discrepancies, Tipalti's PO Matching module delivers native 3-way matching across pre-processing stages 2 (PO match) and 4 (receipt confirmation). The system ingests invoice data via OCR at the line level, then — as documented on Tipalti's PO matching product page — 'when an invoice is received, the system automatically compares it against the corresponding PO and goods receipt,' checks discrepancies against predefined tolerance ranges, auto-approves invoices within tolerance, and flags out-of-tolerance invoices for manual review. The automatic 3-way matching checks vendor name, line items, quantities, and prices against the purchase order and receiving report, detecting discrepancies within pre-established guidelines and error tolerance. Tolerance thresholds are configurable: 'you can create tolerance thresholds based on amounts or percentages and the bill or line level,' so invoices within the threshold are still considered matched. For goods receipt confirmation, Tipalti captures item receipts on auto-pilot by prompting requesters to log Goods Received directly in Tipalti or via email, with item statuses automatically updated to facilitate the 3-way PO match. SAP S/4HANA integration is API-based: Tipalti syncs data with SAP S/4HANA for suppliers, purchase orders, receiving data, supplier invoices, payables, account coding, payments, and supplier credits. The critical gap for this buyer is twofold: (1) tolerance configuration is documented only at the bill/line level, with no confirmed per-vendor or per-PO-type granularity — the buyer's requirement for configurable rules per vendor or PO type is not evidenced; and (2) the GR confirmation mechanism is a Tipalti-native requester prompt rather than a passive sync of authoritative SAP MM goods receipt (MIGO) postings, meaning the warehouse team that currently posts GRs in SAP S/4HANA would either need to confirm receipt a second time in Tipalti, or the integration's 'receiving data' sync would need to replace that step — a mechanism not unambiguously documented.

Limitations: Tolerance rules are documented at the bill/line level (amount or percentage) but no source confirms per-vendor or per-PO-type threshold granularity, which is a buyer-stated requirement; the GR confirmation model relies on a Tipalti-native requester prompt rather than a confirmed passive sync of SAP S/4HANA MM goods receipt postings, introducing either duplicate confirmation work for the warehouse team or a gap in the authoritative GR data source underpinning the 3-way match.

Buyer requirement: When a 3-way match fails on any of the 6,000 PO-based invoices, the system must automatically route the exception to the correct resolver (warehouse for receipt discrepancies, purchasing for price or terms discrepancies) with the full PO line, receipt record, and invoice line presented side by side in the exception task. Exception routing must support escalation on timeout and reroute when the assigned resolver is unavailable, so that the central AP team does not need to manually chase resolution as they currently do.

For a buyer running 6,000 PO-based invoices monthly through a central AP team that coordinates with warehouse and purchasing, Tipalti covers the foundational 3-way match layer but falls materially short on the intelligent, role-differentiated exception routing this requirement demands. Tipalti's PO Matching module performs 3-way matching against POs and GRNs with configurable tolerance thresholds at the bill or line level; when an invoice exceeds tolerance, the exception is flagged with color-coded highlights and exception approval rules are triggered, allowing designated approvers to act via email without logging into the platform. The Approval Routing AI determines the correct approver based on factors including amount, department, and vendor type, and a static escalation mechanism exists: the 'Escalate bills to' configuration in Manage Bills lets an administrator assign a manager who receives the bill if the primary approver has not acted. SAP S/4HANA integration syncs suppliers, POs, receiving data, invoices, payables, account coding, and payments in real time using advanced sync logic that covers entity-specific sub-ledgers. However, three capabilities this buyer's requirement specifically depends on are not documented in any Tipalti source: (1) automatic routing of exceptions to different resolver groups based on discrepancy TYPE (receipt quantity failure routed to warehouse; price or terms failure routed to purchasing) rather than a single exception approver pool; (2) a structured resolver workspace that surfaces the PO line, SAP goods receipt record, and invoice line side-by-side within the Tipalti exception task itself; and (3) dynamic rerouting when the assigned resolver is unavailable, as distinct from static manager escalation. Without discrepancy-type-based branching, every exception lands in the same approver queue, replicating the manual triage and chasing problem the buyer is trying to eliminate.

Limitations: The absence of discrepancy-type routing means AP will still need to manually determine whether a failed match is a receipt issue (warehouse) or a price issue (purchasing) and forward accordingly, precisely the manual chasing the buyer described. Static escalation to a single manager does not substitute for out-of-office rerouting to an alternate resolver in the correct functional group.

Buyer requirement: For PO-backed invoices (expected as standard in a mid-market manufacturing operation), the system must perform 3-way matching: purchase order lines, goods receipt or warehouse confirmation, and invoice lines, with configurable tolerance rules and automatic exception routing when a mismatch is detected. 2-way matching that bypasses receipt confirmation (stage 4 of the pre-processing journey) is insufficient for a manufacturing environment where physical receipt of goods is a distinct event.

For this mid-market manufacturer processing 1,200 invoices per month on Sage Intacct, Tipalti's PO Matching module handles all three legs of the match the buyer requires. When a PO-backed invoice arrives, Tipalti AI Smart Scan extracts data at the header and line-item levels; the system then automatically compares those line items against the corresponding purchase order and goods receipt note (GRN), covering stage 2 (PO match) and stage 4 (receipt confirmation) of the pre-processing journey. Goods receipt capture is handled inside Tipalti's Procurement module: requesters are prompted to log 'Goods Received' directly in Tipalti or via email at the appropriate moment in the PO lifecycle, item statuses are updated automatically, and approved POs plus GRNs sync bidirectionally to Sage Intacct Vendor and Billing management through Tipalti's pre-built Sage Intacct integration. On the tolerance and exception side, administrators configure acceptable variance thresholds by amount or percentage at both the bill level and the individual line level; invoices whose discrepancies fall within tolerance auto-approve, while those outside tolerance are flagged and routed to a designated reviewer through a structured exception workflow before payment can proceed.

Limitations: The GRN capture mechanism relies on Tipalti's internal 'Goods Received' logging workflow (requester-prompted inside Tipalti or via email) rather than an automated pull from Sage Intacct's native purchase receipt records or a connected WMS; manufacturing operations that already create receiving records directly in Sage Intacct or a warehouse management system will need to confirm how receipt data flows into Tipalti's 3-way match engine to avoid a dual-entry step. The Procurement module (which owns the goods receipt workflow) is a separately licensed product from the core AP automation module, so buyers should verify it is included in their contract scope.

Buyer requirement: The system must perform AI-assisted 3-way matching across all three document legs: the SAP S/4HANA purchase order (line by line), the SAP goods receipt (GR) document confirming physical inventory receipt, and the supplier invoice. For the approximately 2,450 PO-based invoices processed each month (70% of 3,500), matching must operate at the line-item level, not just header totals, and must apply configurable quantity and price tolerance rules to distinguish auto-approvable variances from true exceptions requiring human review.

For a manufacturing company running 3,500 invoices per month with 70% PO-based volume, Tipalti's AP automation platform offers documented 3-way matching across the PO, GRN (goods receipt note), and supplier invoice legs, with tolerance rules that operate at both header and line level. Tipalti applies a matching tolerance range configurable by bill or line level, using amounts or percentages, specifically to distinguish auto-approvable variances from mismatches that require review. This tolerance feature reduces the need to manually review acceptable mismatches between invoices, POs, and GRNs; when the difference exceeds tolerance, AP can dispute the bill or trigger a PO update in the ERP. The platform covers pre-processing journey stages 2 (PO match) and 4 (receipt confirmation) together — but the critical unresolved question for this buyer is whether Tipalti's SAP S/4HANA connector pulls live goods receipt documents directly from SAP's MM module (the MIGO/goods movement transaction that posts physical inventory receipt), or whether the GR leg must originate from Tipalti's own Procurement module's receiving workflow. Tipalti's integration documentation states it syncs 'purchase orders (POs), receiving data, supplier invoices, payables, account coding, payments, and supplier credits' with SAP S/4HANA — but the direction and document type of 'receiving data' is not specified in any publicly available help center article retrieved. If the GR leg requires receiving to be recorded inside Tipalti Procurement rather than pulling confirmed SAP MM goods receipts, the buyer's physical inventory workflow (which generates GRs natively in SAP S/4HANA) would require a separate receiving step outside their existing SAP process, undermining the end-to-end chain. Tipalti publicly commits to '2 and 3-way PO matching' in its supporting content, and the AI label applies primarily to invoice capture via Smart Scan; no public documentation was found confirming an ML model that specifically learns from historical exception resolutions to improve auto-match rates over time.

Limitations: The material ceiling for this SAP S/4HANA manufacturing buyer is the GR document source question: no publicly available documentation confirms that Tipalti's SAP connector pulls live MM goods receipt documents (MIGO-originated GR postings) as the third matching leg, rather than requiring receiving to be recorded inside Tipalti's own Procurement module. If the GR leg must be created in Tipalti rather than read from SAP's MM module, the buyer faces a parallel receiving workflow that conflicts with their existing SAP-native inventory receipt process, and the 'AI-assisted' label is not substantiated by documented ML-driven auto-match learning at the matching engine level.

Buyer requirement: Exception routing must be driven by the specific reason a 3-way match fails, not by a generic 'exception' flag. Price discrepancies must route to the procurement or contract owner who holds the agreed terms; quantity discrepancies must route to the warehouse or receiving team who can confirm or correct the GR; invoice legitimacy questions must route to the AP team. This separation is essential because the buyer's 5-person team is currently absorbing all exception types indiscriminately, which is the primary productivity bottleneck at the receipt confirmation and terms verification stages of the pre-processing journey.

For a manufacturer running 3,500 invoices per month with 70% PO-based, Tipalti operates at stages 2 through 4 of the pre-processing journey: it performs 3-way matching against PO and goods receipt, applies configurable tolerance thresholds by amount or percentage at bill or line level, and flags exceptions when those thresholds are exceeded. When an invoice is received, the system automatically compares it against the corresponding PO and goods receipt, checks whether discrepancies fall within predefined tolerance ranges, and uses AI to identify discrepancies and flag them for extra review. Tipalti's Approval Routing AI then determines which approver receives the flagged invoice: with the help of AI and ML, the system determines the correct approver based on factors like amount, department, and vendor type, and analyzes historical data to accelerate both simple and complex approval flows. The critical gap for this buyer is that this routing logic operates at the invoice level by invoice attribute (amount, vendor, department), not at the discrepancy-reason level. If discrepancies exceed the defined tolerance range, the invoice is flagged for further review, triggering a workflow where someone manually investigates the discrepancy, contacts the supplier, or decides about approval or rejection. There is no documented mechanism in Tipalti's platform that branches routing based on the specific failure type: price deviation routing to the procurement or contract owner, quantity deviation routing to the warehouse or receiving team, and legitimacy flags routing to AP. Tipalti's documentation recognizes quantity deviation and price deviation as distinct discrepancy concepts, but the documented exception handling consolidates all out-of-tolerance conditions into a single hold status requiring manual human triage to determine root cause and re-assign — which replicates the buyer's exact current bottleneck.

Limitations: Tipalti's exception routing is driven by invoice-level attributes (amount, vendor type, department) rather than by the specific match failure reason, meaning price discrepancies and quantity discrepancies land in the same review queue and require the same 5-person team to manually triage and re-route them: precisely the productivity bottleneck the buyer is trying to eliminate. No documented configuration allows the system to bifurcate price exceptions to the contract/procurement owner and GR quantity exceptions to the warehouse team automatically.

Buyer requirement: For the roughly 1,050 non-PO invoices processed each month (the remaining 30% of 3,500), the system must support AI-assisted GL coding and cost allocation routing to the appropriate budget owner for approval, since these invoices do not have a PO or GR document to anchor a 3-way match. The coding model must suggest SAP cost objects (cost center, GL account, plant) based on vendor history and invoice content, and must route to the correct budget owner based on the suggested cost allocation rather than defaulting to a fixed AP-team approval chain.

For the 1,050 monthly non-PO invoices arriving at this manufacturer, Tipalti's Auto-Coding AI handles stage 5 of the pre-processing journey (cost allocation) through its Smart Scan and auto-coding engine. Tipalti's AI automates coding by recognizing consistent coding patterns at the header and line-item levels, including custom fields like department, location, tax codes, and expense accounts. Tipalti's Auto-Coding AI predicts the correct GL for each line with up to 95% accuracy and also learns to predict other bill fields including cost centers, expense accounts, location, projects, and departments. Non-PO invoices are recognized as a distinct path: the system lets you set up rules to determine if an invoice is PO-backed and if it should go through the matching process, routing non-PO invoices to a coding-and-approval flow rather than a match flow. On the approval side, AI-driven routing automatically directs invoices to the right approvers based on your organizational structure, with custom approval flows configurable at both header and line-item levels. The system routes invoices to the right stakeholders for approval based on rules and context, and the AI also learns from past activity to recommend faster, more accurate approval paths. For SAP S/4HANA, Tipalti syncs data with SAP S/4HANA ERP for suppliers, purchase orders, receiving data, supplier invoices, payables, account coding, payments, and supplier credits, and Tipalti helps SAP S/4HANA clients strengthen controls and accelerate visibility, with advanced sync logic that ensures entity-specific sub-ledgers are accurately synced in real time. However, two material gaps prevent a 'supported' rating for this specific requirement. First, no Tipalti documentation confirms that 'plant' (an SAP MM organizational dimension this manufacturer will need for cost object completeness) is among the synced or suggested dimensions; Tipalti names cost centers, departments, locations, and GL accounts but not plant codes. Second, approval routing happens automatically based on custom logic tied to the organizational chart, budget lines, and policy-based rules, which describes configuration-time rule mapping, not a runtime resolution of the budget owner from the AI's suggested cost center against SAP cost center master data. The buyer's requirement is that the approver is determined at runtime by following the suggested cost allocation back to its owner in SAP's CO hierarchy, rather than by a pre-configured vendor-to-approver rule; this dynamic resolution mechanism is not documented.

Limitations: Tipalti does not document 'plant' as a suggested SAP cost object dimension, which is a gap for a manufacturer whose non-PO spend must be coded to the correct plant before posting. More critically, approver resolution appears to be driven by pre-configured organizational rules rather than a runtime lookup against the SAP cost center hierarchy, meaning the buyer would need to manually maintain an approver-to-cost-center mapping in Tipalti rather than inheriting it dynamically from SAP CO master data; any cost center hierarchy change in SAP would require a parallel update in Tipalti's routing configuration.

Buyer requirement: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For a real estate portfolio running 8 entities across NetSuite, Tipalti's PO Matching module paired with Tipalti Procurement handles both Stage 2 (PO terms verification) and Stage 4 (receipt confirmation) natively within the platform. At Stage 2, <a href='https://tipalti.com/en-eu/integrations/oracle-netsuite/'>Tipalti's NetSuite integration</a> provides '2-way and 3-way PO matching for headers and line levels, in addition to configurable tolerance matching' — meaning invoice line items are checked against PO unit price and quantity before advancing, not just at the header total. At Stage 4, receipt confirmation is a native Tipalti gate: <a href='https://tipalti.com/procurement/po-management/'>requesters are prompted to log Goods Received directly in Tipalti or via email</a>, item statuses are automatically updated, and the 3-way match cannot complete until GRN confirmation is recorded — this is not a passive ERP sync but an active workflow step. Tolerance rules are configurable at both the bill and the line level by amount or percentage, and when a variance exceeds the threshold, <a href='https://tipalti.com/en-uk/resources/learn/3-way-match/'>Tipalti AI flags the exception and notifies the appropriate stakeholders automatically</a> without requiring full invoice rejection. The multi-entity layer supports entity-specific approval flows, and <a href='https://tipalti.com/press/netsuite-multi-entity-po-match-pr/'>Tipalti automatically syncs POs and GRNs from NetSuite and updates PO and bill statuses back in NetSuite</a>, preserving full data fidelity across the 8 entities.

Limitations: Tolerance rule configuration is documented at the bill or line level but vendor documentation does not explicitly confirm that thresholds can be set with distinct values per entity (e.g., a tighter 1% cap on commercial construction entities versus 5% on residential); buyers with divergent tolerance policies across entities should verify this granularity during implementation scoping. The goods-received logging step requires requesters to actively confirm receipt in Tipalti or via email prompt, meaning the Stage 4 gate depends on requester adoption discipline — a process change for teams currently relying on passive ERP inventory receipts.

Buyer requirement: The system must support 3-way matching of purchase order, receipt confirmation, and invoice for goods and subcontractor-based transactions in construction, where receipt confirmation is captured as a project manager or superintendent contribution within the pre-processing workflow rather than assumed from a warehouse scan. 2-way matching that skips receipt confirmation is insufficient for a construction environment where work confirmation comes from field personnel, not a receiving dock.

For a multi-location construction company on NetSuite where subcontractor receipt confirmation comes from field personnel rather than a warehouse dock, Medius supports genuine 3-way matching (PO, goods delivery receipt, and invoice) as a named, documented product capability. The platform can automatically match invoice line details against purchase orders, goods receipts, and/or contracts to resolve discrepancies in invoices, POs, and receivables. The RAD (Rapid Application Delivery) workflow document confirms the mechanism: the system automatically attempts to connect PO lines and goods receipts to the invoice, then once connected, identifies deviations; any deviation out of tolerance is routed to an Analyze step, while invoices within tolerance bypass it entirely. Medius also has a specific feature for the construction scenario where a goods receipt has not yet been registered: a "Show goods receipt deviation first" toggle allows organizations to prioritize missing GRs over price deviations, so invoices with a missing GR are routed to the responsible user first, and only after the GR is completed are any remaining price deviations routed for handling. On the construction vertical specifically, the platform auto-matches invoices to POs and delivery receipts and flags missing documentation or unusual charges before approval. The ceiling for this buyer is how the goods receipt is sourced. Medius's 3-way match mechanism assumes the goods receipt exists as a record in the connected ERP (here NetSuite) and is synced into Medius; the "missing GR" deviation routing is an exception-handling path, not a purpose-built pre-processing contribution step where a project manager or superintendent confirms subcontractor work completion as the receipt leg before matching begins. To enable automated 3-way matching, master data including vendor ledgers, purchase order details, and goods receipts must synchronize seamlessly between the ERP system and the AP automation solution. No documentation found describes a structured, proactive "confirm receipt of services" workflow step designed for field personnel to contribute work confirmation within the pre-processing journey in the absence of an ERP goods receipt.

Limitations: Medius's 3-way match is designed around goods receipts that originate as records in NetSuite before or during invoice processing; for subcontractor invoices where no ERP goods receipt exists, the missing-GR exception route can direct the invoice to a responsible user, but this is reactive exception handling rather than a designed first-class workflow contribution step where a PM or superintendent proactively confirms work completion as the structured receipt leg of the match. Construction companies with high subcontractor volumes and no formal receiving dock will need to evaluate whether their NetSuite GR-entry discipline is strong enough to feed Medius's matching engine, or configure a workaround using the missing-GR deviation routing as a proxy for receipt confirmation.

Buyer requirement: The vendor must provide demonstrable evidence, through references or case studies from distribution or similarly PO-heavy industries, that their tool has closed a receiving gap comparable to the one described: organizations where employees were not recording receipts and three-way match was nonfunctional, and where the tool's proactive receipt confirmation workflow measurably increased receipt capture rates. This is a vendor evaluation criterion, not a configuration requirement, and is specifically scoped to operational procure-to-pay, excluding strategic sourcing, RFQ, or supplier onboarding capabilities.

The buyer's scenario is a distribution company where warehouse and operations staff are not entering goods receipts in NetSuite, leaving three-way match nonfunctional. Medius does operate at the invoice-processing stage and surfaces missing goods receipts as a deviation type: a documented product feature called 'Show goods receipt deviation first' routes invoices with missing GRs to the responsible user before price deviations are handled, prioritizing GR resolution in the AP workflow (Medius Customer Success Top Tips, success.medius.com). Separately, Medius's three-way matching engine requires that goods receipts sync from the ERP to Medius before touchless processing can occur, meaning that unrecorded receipts in NetSuite will create a blocking exception in Medius rather than silently pass to payment. The closest published industry reference is Chadwell Supply, a wholesaler of appliances, electrical fixtures, HVAC systems, and related products, where 'it was important to match invoices to purchase orders and receipts, but a manual system made it almost impossible'; after Medius AP Automation, Chadwell reached 89.4% touchless capture and processed 100,000 invoices per year with automated three-way matching (Medius customer case study, medius.com). NIC Global manufacturing similarly reported that 'matching POs to receipts was difficult, and vendor payments were being delayed' prior to Medius implementation.

Limitations: No published Medius case study explicitly documents a before/after measurement of goods receipt capture rates in an organization where employees were not recording receipts, nor does Medius publish evidence of a proactive outbound notification workflow that prompts warehouse or receiving employees to confirm delivery when a PO's expected delivery date arrives. The Chadwell and NIC Global references confirm PO-matching improvements in PO-heavy industries, but the measured outcomes are touchless invoice rates and processing speed, not receipt capture rates. The receiving gap in the buyer's scenario must be closed primarily by driving GR behavior in NetSuite; Medius will surface missing GRs as blocking exceptions but does not independently prompt non-AP staff to create receipts.

Buyer requirement: The system must execute automated three-way match across the NetSuite PO, the goods receipt record captured via req_3, and the vendor invoice, without requiring manual reconciliation. Match results must be written back to NetSuite so that PO, receipt, and invoice line items are linked at the NetSuite record level, preserving audit lineage inside the ERP rather than only inside the procurement tool.

This distribution company currently has no receiving records in NetSuite, which collapses three-way match to two-way; Medius directly addresses this by treating the goods receipt as a first-class matching object. Medius imports PO lines and goods receipt records from NetSuite into its own matching engine, where AI-powered logic compares invoice lines against both the PO and the GDR at the line level, flagging quantity and price deviations automatically. Medius has a configurable 'Show goods receipt deviation first' feature that prioritizes missing GRs over price deviations, routing the invoice to the responsible user first; only after the GR is completed are remaining price deviations routed for handling. Once the invoice clears matching (or exceptions are resolved), Medius posts the approved vendor bill back to NetSuite, eliminating duplicate data entry and preserving audit trails directly inside the ERP. The Medius for Oracle NetSuite SuiteApps carry 'Built for NetSuite certification,' meaning they follow platform development standards and best practices. The posted vendor bill in NetSuite references the originating PO and links to the item receipt, restoring NetSuite's native PO-to-receipt-to-vendor-bill transaction chain. However, the step-by-step match results: which line deviated, which tolerance was applied, who approved the exception, and when the GR was confirmed: are logged within Medius's own audit trail and workflow history, not written as discrete NetSuite-native transaction records. Medius ensures that invoice approvals update ERP financial records instantly and reporting reflects real-time information, but the buyer's requirement that audit lineage be preserved 'inside the ERP rather than only inside the procurement tool' is only partially met: the linked document chain (PO, receipt, vendor bill) is intact in NetSuite, but the exception-handling and match-step log resides in Medius.

Limitations: The buyer specifically requires match results and exception-handling lineage to be written back to NetSuite at the record level so auditors can trace the full match history inside the ERP; Medius stores the detailed match workflow log (deviations flagged, approver actions, GR confirmation timestamps) inside its own platform, not as NetSuite-native transaction notes or workflow state records, meaning the full audit chain requires access to both systems. Additionally, the 'Show goods receipt deviation first' feature requires that the NetSuite integration be configured to import PO lines before GRs are completed, so the buyer must validate that their NetSuite connector configuration supports this sequence.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a mid-market distributor on NetSuite whose three-way match today is broken by missing receiving records, Medius addresses both halves of this requirement: tolerance-based auto-approval and defined-handler exception routing. On the tolerance side, Medius exposes configurable 'Deviation Tolerances' and 'Connection Tolerances' at the company and supplier level, set as either a flat amount or a percentage, with separate limits for positive and negative deviations; invoices whose variances fall within those bands are auto-approved and flow straight to ERP posting without human touch. On the exception-routing side, the platform's standard 'Analyze' workflow stage receives every invoice with an out-of-tolerance deviation, routes it to the responsible user with full context across the PO, goods receipt, and invoice documents, and surfaces unit price deviations and quantity deviations as distinct line-level fields so the handler can see exactly which document diverges and by how much. A 'Show goods receipt deviation first' toggle additionally lets the buyer prioritize missing-GR exceptions over price deviations, routing them sequentially rather than simultaneously. The three-way matching rules and tolerances live in Medius rather than in NetSuite's native logic, and Medius connects to NetSuite via a pre-packaged connector.

Limitations: The buyer must align tolerance settings in both Medius and NetSuite; if NetSuite's own matching thresholds are tighter than what Medius approves, invoices can re-queue for manual attention inside the ERP after Medius has already cleared them, creating a dual-approval burden that requires configuration discipline at go-live.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For this buyer's 55% PO-based invoice volume covering facilities, supplies, and subcontractors, Medius executes automated three-way matching by synchronizing vendor ledgers, purchase order details, and goods receipts from Sage Intacct into the matching engine, then comparing the inbound invoice against all three documents before routing. To enable automated 3-way matching, Medius requires that master data including vendor ledgers, purchase order details, and goods receipts synchronize seamlessly between the ERP system and the AP automation solution. When all data aligns within applied tolerance levels, the invoice flows touchless to ERP posting without manual review. When all data on the invoice matches supporting documents and applied tolerance levels, the invoice can go directly from receipt and data capture to final posting in the ERP for payment without anyone reviewing or touching it. The buyer's specific 2% price and 5% quantity thresholds are directly configurable via Medius's connection tolerance feature: an admin or AP user can specify an acceptable range in amount or percentage for automatic connection at the header or line level, this can be done at the company and supplier levels, with separate limits settable for positive and negative deviations, allowing automatic connection between invoice and purchase orders or goods receipts as long as amounts are within the defined threshold. Invoices that fall outside tolerance are classified as deviations and surfaced for exception routing, covering both pre-processing journey stage 2 (PO match) and stage 4 (receipt confirmation). Automated systems allow for flexible tolerance levels, ensuring that minor discrepancies in quantities or pricing are automatically processed without delay.

Limitations: The goods receipt must originate in Sage Intacct (or be registered there by the receiving team) before the match can execute; if the buyer's receiving staff delays entry of goods receipts into Sage Intacct, invoices will queue in an exception state awaiting the receipt record rather than routing automatically. For the buyer's 45% non-PO invoices (utilities, subscriptions, insurance), three-way matching does not apply and those invoices follow a separate coding and approval path without receipt confirmation.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a services company running 55% PO-based invoice volume across 6 locations and 2 Sage Intacct entities, JAGGAER's Invoicing module covers all three legs of the match at stage 4 of the pre-processing journey: receipt confirmation is a native gate in the workflow. The platform's matching engine supports configurable 2-way, 3-way, and n-way matching rules applied against POs, receipts, and invoices, with tolerance bands set separately for price (cost) and quantity at the 'AP Administration > Matching Rules and Tolerances' admin pages. Invoices that fall within both tolerance thresholds are automatically marked as payable and skip manual review; invoices outside tolerance are routed as match exceptions for AP review, with the Matching tab displaying PO details, tolerance detail, and every rule evaluated for auditability. Because JAGGAER is a full source-to-pay platform, its matching engine is natively strongest when POs and goods receipts are generated within JAGGAER itself; when deployed as an AP-only layer on top of Sage Intacct (where this buyer's POs and GRs originate), implementation scoping must confirm that the ERP integration carries goods receipt records from Sage Intacct into JAGGAER automatically, rather than requiring AP staff to manually enter receipts inside JAGGAER to trigger 3-way matching.

Limitations: The critical integration question for this buyer is receipt data flow: JAGGAER's help center documentation notes that end users must have receipts entered before an invoice can be matched or flagged as an exception, so the buyer must verify during scoping that JAGGAER's Sage Intacct connector ingests goods receipt records automatically and not just PO header and line data. If GR data does not flow automatically, AP staff would need to manually log receipts in JAGGAER, reducing the touchless processing value for the buyer's PO-based volume.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For this $120M multi-location services company processing 55% PO-based invoices across two Sage Intacct entities, JAGGAER's native matching engine covers all five stages of the pre-processing journey for PO-backed transactions. JAGGAER's AP module applies configurable 2-, 3-, and n-way matching rules to POs, receipts, and more, with built-in alerts and collaboration tools that streamline exception handling to keep processes moving efficiently. The tolerance configuration is buyer-administered: matching configuration options including rules and tolerances are configured at AP Administration > Matching Rules and Tolerances pages. The system supports percentage-based thresholds, as documented in the official help center: an organization may set tolerances of 3% above the cost and 10% below the cost, and whenever documents meet these criteria, the invoice is automatically matched and marked as payable, confirming the buyer's specific 2% price and 5% quantity thresholds are configurable within the same framework. Receipt confirmation (Stage 4 of the pre-processing journey) is natively integrated: Receipt Lead Time defines the number of days required for a shipment to be received and the receipt to be entered into the system; the auto-match robot holds unmatched invoices that are missing receipts until the receipt has been entered and the invoice has been matched. Invoices that fall outside configured tolerance bands are routed to an exception queue rather than auto-approved: the system categorizes PO/Invoice/Receipt matches as Within Tolerance, Outside of Tolerance, or Do Not Match, enabling the AP team to review only true exceptions. AI automatically matches invoices to purchase orders and goods receipts even when formats vary, evaluates tolerance thresholds, historical patterns, and supplier behavior to determine whether an invoice can proceed or requires review, and where exceptions do occur, AI-supported exception handling helps teams focus on what genuinely needs attention.

Limitations: The official help center documentation confirms percentage-based cost and quantity tolerance configuration but does not explicitly state whether tolerances are enforced at the invoice line-item level versus the invoice header total; given JAGGAER's PO-line architecture this is strongly implied but not definitively confirmed in the sources found. Additionally, if the buyer allows non-PO lines on invoices, the automatic process of holding invoices until matched should not be used, as the process will attempt to match all lines and an invoice with non-PO lines may not complete the workflow step depending on configuration, which is relevant given the buyer's 45% non-PO invoice volume and will require careful workflow segmentation.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M multi-location services company running 55% PO-based invoices across facilities, supplies, and subcontractors, JAGGAER's Invoicing module addresses all five pre-processing stages, with three-way matching covering stage 2 (PO match), stage 3 (terms verification), and stage 4 (receipt confirmation) natively. JAGGAER's Intelligent Matching and Exceptions capability supports 2-, 3-, and n-way matching with configurable tolerances to speed resolution and reduce manual effort. Mechanically, an invoice is cross-referenced against the originating PO and the entered goods receipt; in addition to tolerances, the automated matching process can hold invoices pending receipt entry (called Receipt Lead Time), and invoices that require a receipt for matching but have not yet had one entered are identified as match exceptions and held until matched or the lead time expires. Tolerance thresholds for both price and quantity variances are percentage-based and set by the buyer's own administrators: matching configuration options including rules and tolerances are configured at AP Administration > Matching Rules and Tolerances pages. The help center explicitly illustrates percentage tolerances such as "3% above the cost and 10% below the cost" as a sample configuration, confirming the buyer's specific 2% price and 5% quantity bands are within the system's configuration model. When an invoice falls outside tolerance, a pop-up displays PO details, tolerance details, and rules evaluated, with the first rule listed being the step where the invoice stopped, giving AP staff a clear reason code for every exception. Anomalies such as price variances, quantity mismatches, or duplicate invoices are flagged and prioritized based on risk and materiality, reducing blanket manual checks.

Limitations: The help center notes that matching configuration "is typically handled by an administrator and is configured during implementation, and occasionally updated on an as-needed basis," which may mean tolerance updates require engagement with JAGGAER Support rather than self-service; the buyer should confirm at-will admin reconfiguration of tolerance bands is available without a professional services engagement. JAGGAER is architected primarily for complex, high-volume procurement environments, so the full Source-to-Pay suite may carry implementation and licensing overhead that exceeds the scope of a 3-person AP team at 1,800 invoices per month; fit and total cost of ownership at the buyer's scale should be validated.

Buyer requirement: Automated three-way matching: PO to receipt to invoice with configurable tolerance (2% price, 5% quantity)

For a $250M technology company moving off email/Slack approvals, Basware AP Automation provides genuine three-way matching across all three documents. Purchase orders can be imported for 2-way matching without receipts and for 3-way matching with goods receipts. The goods receipt leg is ingested via Basware's XML or REST API, which carries row-level quantity, net price, and net sum for each GR line, and the 'Matching against goods receipts' option configures whether the Order Matching function includes matching against goods receipts; when enabled, the Order Matching function matches purchase invoices to the receipt row of the order. Tolerance is configurable: the Tolerance setting in Purchase Invoice Settings configures the basis for purchase invoice approval in Order Matching, a supplier-specific tolerance can be set in supplier maintenance, a global fallback applies when no supplier-specific tolerance is configured, and approval can be based on a percentage or monetary amount compared against the invoice total and the matched order row total. You can establish acceptable tolerance thresholds for minor discrepancies; when invoices fall within defined tolerances they proceed through automated approval, and only genuine discrepancies that exceed your thresholds are routed to your team for investigation. The documented tolerance mechanism in the current Alusta/Neo platform compares the invoice total against the matched order-row total as a single percentage or monetary value; the available help documentation does not confirm that price variance and quantity variance can be set as two independent percentage axes (e.g., 2% price separately from 5% quantity). A Matching Discrepancy Task is triggered when an invoice fails to match its corresponding documents, routing the exception to an AP reviewer worklist rather than blocking payment silently.

Limitations: The current-platform (Alusta/Neo) tolerance configuration documented in Purchase Invoice Settings applies a single total-level percentage or monetary threshold comparing invoice total to order-row total; independent price-axis (2%) and quantity-axis (5%) tolerance rules as two distinct configurable parameters are not confirmed in Basware's current cloud help documentation, which means the buyer's specific dual-axis tolerance requirement may not be satisfiable without implementation workarounds or custom configuration. Additionally, the goods receipt leg depends on PO and GR data being imported from NetSuite via Basware's XML/API integration, so the NetSuite-to-Basware integration must be in place and configured to pass receipt records before true three-way matching can execute.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a services company processing 1,800 invoices per month with 55% PO-backed (facilities, supplies, subcontractors), Basware's matching engine covers the full pre-processing journey through Stage 4: receipt confirmation. PO-backed invoices are automatically matched to POs, goods receipts, and any other required matching points, addressing the buyer's three-way match requirement directly. The InvoiceAI suite, which includes the SmartPDF, Basware Guardian for AP, SmartMatching, and AP Matching Agent tools, drives this matching at the line level: it performs real-time data checking, line-item matching, and automatic postings. Basware's help documentation confirms three distinct matching methods, including receipt-row matching, and that approval is based on a percentage or monetary amount comparison; if the difference falls within the tolerance the invoice is approved automatically, and if above or below tolerance it is sent to the standard approval workflow; the tolerance and threshold values can be defined at the supplier level or at the settings level in Purchase Invoice Settings. This means both the buyer's 2% price tolerance and 5% quantity tolerance are directly configurable parameters, not hardcoded values. Acceptable tolerance thresholds for minor discrepancies, such as slight quantity variations or freight charge fluctuations, can be established; when invoices fall within defined tolerances they proceed through automated approval. Exceptions that fall outside tolerance are routed for review with reason codes: Invoice Matching automatically applies a root cause error description to any invoices that cannot be posted automatically.

Limitations: The tolerance configuration granularity visible in documentation describes supplier-level and global settings-level configuration; evidence of line-category-level tolerance rules (e.g., a separate tolerance band specifically for subcontractor POs versus facilities POs) is not documented in the sources found. Basware's platform is architected for large enterprises, and for a mid-market buyer at 1,800 invoices per month, implementation complexity and per-invoice pricing may represent a cost ceiling worth validating during a commercial discussion.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M multi-location services company processing 1,800 invoices per month with 55% PO-backed spend across facilities, supplies, and subcontractors, Ivalua's 'Smart Matching' engine inside its AP Automation and Invoice-to-Pay module covers the full pre-processing journey through stage 4 (goods receipt confirmation). The matching engine compares invoice content against POs, contracts, and goods receipts in a single workflow: Smart Matching matches invoice content against purchase orders, contracts, blank orders, and goods receipts before confirming tax treatment and allocating the invoice item to a budget or cost center. On the tolerance configuration side, with Ivalua's no-code/low-code procurement platform, buyers can configure approval chains and matching tolerances to reflect their actual business policies instead of using generic templates. Invoices that fall within the defined tolerance policy auto-process; those outside it are flagged and routed by exception type: AI analyzes what types of discrepancies exist and routes the problem to the appropriate department, for example a price variance goes to Procurement while a quantity mismatch goes to Receiving. Ivalua automates three-way matching by linking the PO, invoice, and goods receipt into a single workflow; it compares quantities, prices, and delivery confirmations automatically, moves matched invoices straight through for payment, and flags discrepancies such as a price mismatch or missing receipt for routing to the appropriate stakeholder.

Limitations: No publicly available help center documentation confirms that price tolerance and quantity tolerance are configurable as independently named percentage bands (i.e., a discrete 2% price field and a discrete 5% quantity field); Ivalua's documentation consistently describes configurable tolerances in aggregate terms, so buyers should validate in a demo that both dimensions can be set separately. Ivalua is also a full Source-to-Pay platform sized for enterprise buyers, which typically means higher implementation complexity and cost relative to standalone AP automation tools; a $120M company should confirm that the mid-market implementation path delivers the matching configuration depth documented for enterprise deployments.

Buyer requirement: Automated three-way matching: PO to receipt to invoice with configurable tolerance (2% price, 5% quantity)

For a $250M technology company currently reconciling POs manually in NetSuite, Ivalua's AP Automation module handles the full three-way match within a single Source-to-Pay platform. Three-way matching is a core part of Ivalua's PO automation: the platform links the PO, invoice, and goods receipt into a single workflow for real-time comparison of quantities, prices, and delivery confirmations automatically, and if everything aligns the invoice moves straight through for payment. The matching engine is called Smart Matching; it matches invoice content against purchase orders, contracts, and goods receipts before confirming tax treatment and allocating the invoice item to a budget or cost center, using intelligent workflow to enable high levels of straight-through processing. Tolerance configuration is explicitly supported: using Ivalua's no-code/low-code platform, teams can configure approval chains and matching tolerances to reflect actual business policies, with configurable thresholds and rules-based logic ensuring invoices are flagged automatically for amount discrepancies, missing PO matches, or duplicate entries. During smart matching, exceptions such as cost or volume tolerance violations are surfaced and resolved via one-click email approval, allowing off-line resolution without AP having to manually track down stakeholders. The process covers stage 4 of the pre-processing journey (receipt confirmation through payment clearance): the Invoice Hub is embedded within AP rather than isolated, so supplier credit controllers can upload, validate, and match their invoices to Source-to-Pay data via the supplier portal, and only compliant, valid invoices flow into the payables journey.

Limitations: While Ivalua documents configurable 'cost tolerance' and 'volume tolerance' as distinct exception types, public documentation does not explicitly confirm that these two tolerance percentages (2% price, 5% quantity) can be set independently at the category or supplier level rather than as a single system-wide rule; buyers should validate per-category tolerance granularity during demo. No glass ceiling concern applies here since Ivalua is a native Source-to-Pay suite, not an ERP-native AP module.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M services company running 55% PO-based invoices across facilities, supplies, and subcontractors, Vic.ai's Autonomous PO Matching module handles pre-processing stages 2 through 4: PO line matching, terms verification, and receipt confirmation. The AI extracts line-item data from each invoice and compares it against the corresponding PO lines, evaluating quantities, unit prices, and descriptions; and, when a goods receipt is present, performs a full three-way match against the receipt as well. Vic.ai's help center documents that 'you can set acceptable tolerances' for price and quantity variances, and that a dedicated tolerance generator lets organization and company admins set how exact the match must be across different values; invoices that fall within those thresholds clear automatically, while items outside them are routed to a designated PO Mismatch Approver for resolution. Discrepancies are identified at the line-item level with a cited explanation of the rule violation, so the AP team can resolve exceptions without reconstructing context from email chains.

Limitations: The help center documents that tolerance configuration operates at the organization and company level; there is no public documentation confirming that separate tolerance rules can be set per vendor, per location, or per PO line category (e.g., 2% price tolerance for supplies vs. a different threshold for subcontractors), so buyers with highly differentiated tolerance schedules should verify that granularity during a demo. Receipt confirmation in three-way matching relies on receipt records being available in Vic.ai (imported from the ERP or a connected procurement system); if the buyer's receiving workflow is entirely offline or outside Sage Intacct, receipt data must be fed to Vic.ai for stage 4 to trigger automatically rather than falling back to two-way matching.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a multi-location services company running 55% PO-based volume through Sage Intacct, Yooz addresses pre-processing stages 2 (PO match) and 4 (receipt confirmation) within its matching engine. When an invoice arrives, Yooz captures it via any channel and uses AI-driven OCR to extract line-level detail: product codes, descriptions, quantities, and unit prices. It then automatically pulls purchase orders and receipts directly from Sage Intacct's purchasing module, so goods receipt data from your existing ERP workflow feeds the match without a separate manual step. The engine performs a three-way comparison: invoice line by line against the PO line and the goods receipt, checking quantity, price, and totals at the line level rather than just document totals. Invoices that fall within your configured tolerance thresholds are auto-approved and flow straight to payment; those outside tolerance are flagged as exceptions and routed to a designated reviewer based on the discrepancy type or threshold exceeded. A recent April 2026 product expansion explicitly added AI-driven line-level PO matching with configurable routing based on discrepancy type or threshold and one-click exception handling.

Limitations: Yooz's public documentation confirms that tolerances are customer-configurable and applied separately to price, quantity, and item variances, but no help-center article explicitly shows a side-by-side price-tolerance field and quantity-tolerance field within a single matching rule, so the buyer should validate during a demo that a 2% price tolerance and a 5% quantity tolerance can be set independently in the same rule. Goods receipt data is pulled from Sage Intacct's purchasing module, meaning receipt records must be posted in Sage Intacct before Yooz can execute the third leg of the match; invoices arriving ahead of a posted receipt will stage as pending until the GRN is recorded.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M multi-location services company on Sage Intacct with 55% PO-based invoices, Ramp's matching covers stages 2 and a partial stage 4 of the pre-processing journey, but with a material constraint specific to Sage Intacct. Ramp performs 2-way matching natively in its Bill Pay module: OCR reads the incoming invoice, auto-suggests the linked PO by vendor or PO number, and matches bill line items to PO line items. However, for Sage Intacct specifically, the goods receipt confirmation leg does not execute inside Ramp: the 2-way matched bill syncs back to Sage Intacct, where the 3-way match against the item receipt occurs within the ERP, rather than being managed, flagged, or blocked from within Ramp's own UI. By contrast, NetSuite customers get native item receipt import into Ramp where the platform shows line-by-line received/not-received status and alerts before approval. On the tolerance side, Ramp's Overbilling Protection allows admins to set a configurable threshold as either a percentage of the total invoice amount or a flat dollar amount, which can block bill creation when the invoice exceeds the PO by more than the threshold. The supporting fact sheet also confirms line-item-level matching and check mechanics. What is absent for Sage Intacct is (a) native goods receipt management inside Ramp with line-by-line status visibility before approval, (b) quantity-level line item matching within Ramp's UI, which is documented only for NetSuite and QBO customers, and (c) separate configurable price-variance and quantity-variance tolerance thresholds at the line level; the overbilling protection applies to the invoice total, not distinct 2% price and 5% quantity bands per line.

Limitations: For this buyer's Sage Intacct environment, Ramp does not natively ingest or track item receipts within its own UI: goods receipt confirmation defers to Sage Intacct, meaning AP cannot see or enforce receipt status before approving payment in Ramp itself. Additionally, Ramp's documented quantity-level line item matching requires NetSuite or QBO, and the overbilling tolerance is a single total-amount threshold, not the dual price-percentage and quantity-percentage line-level tolerance this buyer requires.

Buyer requirement: The solution must perform automated 3-way matching (PO line, goods receipt confirmation, and invoice line) for all 6,000 PO-based invoices processed monthly, with configurable quantity and price tolerance rules per vendor or PO type. This addresses pre-processing stages 2 and 4 directly, replacing the manual coordination currently required between the central AP team, the warehouse, and purchasing when quantities or prices do not align.

This buyer runs 6,000 PO-based invoices monthly through a centralized AP team that coordinates with a warehouse and purchasing on mismatches, and needs 3-way matching (PO line + goods receipt + invoice line) with configurable per-vendor or per-PO-type tolerance rules against SAP S/4HANA. Ramp's Bill Pay and Procurement modules do offer documented 3-way matching capability: when enabled in a Spend Program's procurement controls, Ramp can match invoice line items against PO lines and item receipts, surface a 'not received' alert on bill lines, and apply overbilling protection thresholds configured as a percentage or static amount tolerance. However, Ramp's native 3-way match is explicitly scoped to NetSuite, Sage Intacct, and QuickBooks Online for PO import and item receipt sync. SAP S/4HANA is not listed among the supported ERP integrations for PO import and match, and no Ramp help center documentation was found describing a native or direct integration with SAP S/4HANA for any data exchange, let alone the full fidelity required for goods receipt sync. Ramp's own blog acknowledges it 'can be used alongside certain SAP ERP systems' in a generic sense but names only OCR and auto-coding capabilities, not a structured SAP PO or goods receipt integration. The end-to-end process this buyer described, where SAP S/4HANA holds the POs and goods receipt records and Ramp must consume both to execute 3-way matching and post results back, cannot be completed because the integration layer between Ramp and SAP S/4HANA does not exist at the depth required.

Limitations: Ramp's 3-way match with item receipt sync is limited to NetSuite, Sage Intacct, and QuickBooks Online; SAP S/4HANA is not a supported ERP for PO import or goods receipt pull, which means the buyer's entire requirement, centralized AP-driven 3-way matching against SAP records with configurable tolerance rules, cannot be delivered on Ramp without a custom middleware build that Ramp does not provide. Even if a workaround were constructed, Ramp's overbilling tolerance is a single threshold per Spend Program, not a per-vendor or per-PO-type configurable rule, which falls short of the buyer's stated requirement.

Buyer requirement: When a 3-way match fails on any of the 6,000 PO-based invoices, the system must automatically route the exception to the correct resolver (warehouse for receipt discrepancies, purchasing for price or terms discrepancies) with the full PO line, receipt record, and invoice line presented side by side in the exception task. Exception routing must support escalation on timeout and reroute when the assigned resolver is unavailable, so that the central AP team does not need to manually chase resolution as they currently do.

This buyer runs 6,000 PO-based invoices per month through a central AP team that coordinates with warehouse (receipt discrepancies) and purchasing (price/terms discrepancies) when 3-way matches fail. Ramp's Bill Pay and Procurement modules do support 3-way matching at the line-item level: when a bill is matched to a PO, Ramp fetches item receipts and flags unmatched lines with a receipt status alert, surfacing which billed line items have not been received. The Bill Pay approval workflow builder supports conditional routing based on bill attributes (amount, vendor, accounting categories, business entity), and custom approval groups can be configured so that, in principle, a 'warehouse' group and a 'purchasing' group could be wired to different exception paths. Delegate approvers exist as a manual coverage mechanism when a resolver is unavailable. However, three material gaps separate this from the buyer's stated requirement. First, Ramp's exception routing is structured around the standard bill approval chain, not a dedicated exception task that presents PO line, receipt record, and invoice line side by side for a specific resolver; the discrepancy is surfaced as a status alert on the bill, not as a role-specific structured exception task. Second, there is no documented automatic timeout-based escalation within the Bill Pay approval workflow; the only timeout mitigation is in-app alerts visible to AP admins and a manual 'send reminder' action once per day, placing the chase burden back on AP. Third, and critically for this buyer's ERP context: Ramp's documented ERP integrations cover NetSuite, Sage Intacct, QuickBooks, Xero, Acumatica, and Microsoft Business Central. SAP S/4HANA is not listed as a supported integration, and Ramp's own blog explicitly notes that 'Ramp has not yet established a formal case study with SAP' and does not name SAP as a connected accounting provider. Without a direct SAP S/4HANA integration, PO import, receipt sync, and post-match write-back to the buyer's ERP of record cannot function as described, which undermines the entire 3-way match and exception-routing chain.

Limitations: The absence of a native SAP S/4HANA integration is a foundational blocker for this buyer: Ramp's 3-way match relies on pulling item receipts from a connected ERP (documented only for NetSuite, Sage Intacct, and QuickBooks), so the receipt-confirmation and post-match sync steps that this workflow depends on cannot execute against the buyer's system of record. Even if an integration were solved, Ramp lacks documented automatic timeout escalation and role-differentiated exception task presentation (warehouse vs. purchasing resolver views), meaning AP would still need to manually chase stalled exceptions.

Buyer requirement: The system must perform AI-assisted 3-way matching across all three document legs: the SAP S/4HANA purchase order (line by line), the SAP goods receipt (GR) document confirming physical inventory receipt, and the supplier invoice. For the approximately 2,450 PO-based invoices processed each month (70% of 3,500), matching must operate at the line-item level, not just header totals, and must apply configurable quantity and price tolerance rules to distinguish auto-approvable variances from true exceptions requiring human review.

This manufacturing buyer runs 2,450 PO-based invoices per month through SAP S/4HANA, where both the authoritative PO line data and the goods receipt (GR/MIGO) documents live. Ramp does offer a 3-way matching capability within its Bill Pay and Procurement modules: 3-way match allows you to match bills in Ramp Bill Pay with purchase orders and item receipts, and once a PO is selected, Ramp will automatically match the bill line items with PO line items and then pull in item receipts. The mechanism covers Stage 4 of the pre-processing journey (receipt confirmation) and does operate at the line-item level for inventory items. However, the GR leg of this match is architecturally tied to a specific short list of ERPs: the PO Import and Match feature is currently only supported for Purchase Orders created in NetSuite, Sage Intacct, and QuickBooks Online. Bill Pay supports all of Ramp's accounting integrations, including QuickBooks Online, Universal CSV (with IIF support for QuickBooks Desktop), Xero, Sage Intacct, NetSuite, Microsoft Business Central, and Acumatica — SAP S/4HANA does not appear in this list. Because the buyer's PO and GR documents of record reside in SAP S/4HANA, Ramp cannot pull those documents into its matching engine. The 3-way match mechanism, which depends on live item receipt import from a connected ERP, is inoperable for this buyer's environment. This is also an ERP glass ceiling failure: Ramp's integration layer tops out well below SAP's data model, meaning the buyer's SAP investment cannot be surfaced through Ramp's AP layer at all.

Limitations: There is no documented SAP S/4HANA accounting or procurement connector in Ramp's help center; the buyer would have no path to feed live SAP PO line data or GR documents into Ramp's matching engine. Even the fallback of Universal CSV is a flat-file mechanism that breaks GR timing accuracy and eliminates the auto-approve-vs-exception routing the buyer needs for productivity gains at 2,450 PO invoices per month.

Buyer requirement: Exception routing must be driven by the specific reason a 3-way match fails, not by a generic 'exception' flag. Price discrepancies must route to the procurement or contract owner who holds the agreed terms; quantity discrepancies must route to the warehouse or receiving team who can confirm or correct the GR; invoice legitimacy questions must route to the AP team. This separation is essential because the buyer's 5-person team is currently absorbing all exception types indiscriminately, which is the primary productivity bottleneck at the receipt confirmation and terms verification stages of the pre-processing journey.

This manufacturing buyer needs exception routing that fires on the specific reason a 3-way match fails: price discrepancy routes to procurement/contract owner, quantity discrepancy routes to the warehouse/receiving team, and legitimacy questions route to AP. Ramp's Bill Pay approval workflow builder does support condition-based routing on bill attributes: amount, vendor, department, and accounting coding fields can all drive separate approval chains, and the platform will surface AI-generated summaries flagging anomalies to approvers in queue (support.ramp.com, 'Bill Pay approvals'; 'AP Agents available in Ramp Bill Pay'). For the receipt/quantity leg of 3-way match, Ramp shows a line-item receiving status alert when billed units have not been received, giving the AP team visibility into which specific lines failed (support.ramp.com, '3-Way Match with Ramp Procurement'). However, the documented routing conditions in Bill Pay approvals are bill-level attributes (amount, vendor, department), not match-failure-reason attributes: there is no documented condition type such as 'match failure reason = price discrepancy' or 'match failure reason = quantity variance' that would automatically fork the workflow to procurement vs. warehouse vs. AP without manual triage. The overbilling protection feature flags amount overages and can block payment, but it does not itself trigger a discrete routing branch to the contract owner vs. the receiving team. The result is that Ramp surfaces the discrepancy visually and can route based on configured conditions, but routing based on the precise match-failure category (price vs. quantity vs. legitimacy) requires the admin to pre-build separate spend programs or approval conditions as proxies, which is an approximation of the buyer's requirement rather than a native match-failure-driven routing engine. Critically, the native 3-way match integration documented by Ramp is with NetSuite, Sage Intacct, and QuickBooks; there is no documented native integration with the buyer's SAP S/4HANA ERP for PO and goods-receipt import, which is a foundational dependency for the entire 3-way match workflow (Ramp blog, 'SAP AP Automation: What It Is and How It Works').

Limitations: Ramp's approval routing conditions operate on bill-level attributes (amount, vendor, department) rather than on the specific reason a 3-way match failed, so routing price discrepancies to the contract owner and quantity discrepancies to the warehouse team requires manual proxy configuration rather than a native match-failure-reason trigger. More critically, Ramp has no documented native integration with SAP S/4HANA for PO and item-receipt import; its 3-way match is natively supported only for NetSuite, Sage Intacct, and QuickBooks, which means the buyer's foundational ERP connection is either absent or requires custom API work.

Buyer requirement: For the roughly 1,050 non-PO invoices processed each month (the remaining 30% of 3,500), the system must support AI-assisted GL coding and cost allocation routing to the appropriate budget owner for approval, since these invoices do not have a PO or GR document to anchor a 3-way match. The coding model must suggest SAP cost objects (cost center, GL account, plant) based on vendor history and invoice content, and must route to the correct budget owner based on the suggested cost allocation rather than defaulting to a fixed AP-team approval chain.

For a manufacturing company processing roughly 1,050 non-PO invoices monthly, Ramp's Bill Pay platform offers an AI auto-coding agent that learns from historical patterns and applies GL code suggestions at the line-item level: the AP Agent automatically assigns accounting codes and categories to invoice line items based on vendor historical patterns and provided invoice context, activated simply by uploading an invoice. On the approval side, there are multiple bill fields on which approvals can be routed, though conditions beyond amount-based routing require Ramp Plus, and for Bill Pay approvals, Ramp resolves the department owner by identifying the department owner of the assigned vendor owner, and the location owner by identifying the location of the assigned vendor owner. This means approver resolution is anchored to the vendor relationship in Ramp, not dynamically to the GL cost center suggested on a specific invoice line, which is the buyer's stated requirement. Most critically, Ramp's own documentation describes the relationship to SAP as being used "alongside certain SAP ERP systems" rather than as a native direct integration: Ramp's documented direct ERP integrations cover NetSuite, QuickBooks, Sage Intacct, Xero, Acumatica, and Microsoft Business Central, with no support.ramp.com help article documenting a native SAP S/4HANA connector. Without a verified native SAP S/4HANA integration, Ramp cannot pull SAP CO master data (cost center hierarchy, plant codes) as suggestion targets, nor can it post suggested cost objects back to SAP with the field fidelity required by an S/4HANA FI/CO environment.

Limitations: Two material ceilings apply simultaneously for this buyer: Ramp has no documented native SAP S/4HANA integration, so the required SAP cost objects (cost center, GL account, plant) cannot be synced as suggestion targets or written back with S/4HANA field fidelity. Even within its supported ERPs, Ramp's Bill Pay approver resolution for department-owner routing is anchored to the vendor's assigned owner, not dynamically to the cost center coded on the invoice, meaning budget-owner routing driven by suggested cost allocation rather than vendor relationship is not the documented mechanism.

Buyer requirement: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For a real estate portfolio running on NetSuite, Ramp's 3-way matching operates through its Procurement and Bill Pay modules in combination. 3-way match allows users to match bills in Ramp Bill Pay with purchase orders and item receipts, giving control over AP to ensure payment only for goods received. The mechanism for Stage 2 (PO terms verification) and Stage 4 (receipt confirmation) works as follows: when paying bills in Ramp Bill Pay, the user matches the bill to a purchase order in NetSuite; once a PO is selected, Ramp automatically matches bill line items with PO line items and pulls in item receipts, allowing the user to view which billed line items have not yet been received. Item receipts can enter the workflow in two ways: if the buyer prefers to receive in NetSuite, Ramp can import those NetSuite Item Receipts and 3-way match them to Ramp purchase orders and bills. A variance control layer exists in the form of Overbilling Protection: this feature blocks payments for invoices exceeding the PO amount, and admins can set a threshold using a percentage of total amount tolerance or a specific static dollar amount; when the threshold is exceeded, a draft bill is created but a final bill cannot be created. On the approval side, Ramp analyzes vendor history, PO matching, and billing patterns at the bill level and surfaces a 'Review recommended' signal when it detects a pricing change or misalignment with the matched PO. However, two gaps are material for this buyer's 8-entity requirement: first, the Overbilling Protection tolerance is documented as a single global account-level setting with no evidence of per-entity scoping; second, the exception routing on variance detection is advisory (a flagged signal) rather than an automatic hard-stop route to a designated entity-level approver. A further architectural constraint: item receipts created in Ramp cannot be synced back to NetSuite, meaning any receipts logged natively in Ramp must also be manually created in NetSuite to keep the ERP's receiving records current.

Limitations: The overbilling tolerance is a single global threshold with no documented per-entity configuration, which means the buyer cannot enforce stricter controls on high-risk commercial construction entities versus residential entities as required. Additionally, the exception routing on mismatch detection is advisory rather than an automatic hard-stop route to a specific entity-designated approver, and item receipts created natively in Ramp do not sync back to NetSuite, creating a data integrity gap for the buyer's ERP of record.

Buyer requirement: The system must execute 3-way matching (PO plus goods receipt confirmation plus invoice) on the approximately 1,850 PO-backed invoices processed each month, with configurable tolerance rules for quantity and price variance, and automated exception routing when a match fails; 2-way matching that bypasses receipt confirmation is insufficient and must not be accepted as compliant with this requirement. This directly addresses stages 2 and 4 of the pre-processing journey for the PO-backed invoice stream.

For a buyer processing roughly 1,850 PO-backed invoices per month in NetSuite, Ramp's Bill Pay module supports genuine 3-way matching across stages 2 and 4 of the pre-processing journey. On the receipt confirmation leg specifically: enabling 3-way match in Bill Pay settings causes Ramp to pull item receipts from NetSuite, and once a PO is selected, Ramp automatically matches bill line items with PO line items and then pulls in the associated item receipts. Once a bill is matched to a PO with item receipts, the receiving status appears directly on each bill line item; if billed units have been received a confirmation appears, and Ramp shows an alert if billed units have not been received. On the tolerance and exception side, Ramp's Overbilling Protection feature provides the ability to block payments for invoices that exceed the PO amount and to set an overbilling threshold using either a percentage of the total amount or a specific static dollar amount. However, this tolerance control operates at the total-amount level: there is no documented mechanism for configurable per-line price variance or quantity variance tolerance bands. When an overbilling threshold is breached, a draft bill is created but cannot progress to a payable bill; the only resolution paths are editing the PO amount or editing the invoice amount, which is a hard stop rather than an automated exception-routing workflow that sends the discrepancy to a designated buyer or approver. A further constraint for this buyer's NetSuite workflow: item receipts created inside Ramp cannot be synced back to NetSuite, so the team must create and manage item receipts in NetSuite to keep the ERP record authoritative. The Bill Pay approval workflow builder does support conditional routing based on bill fields such as amount, business entity, vendor name, and accounting categories, and Ramp flags bills where it identifies a pricing change or misalignment with the matched PO as 'review recommended', but neither mechanism constitutes a structured automated exception queue that routes failed 3-way matches to a specific resolver role.

Limitations: The two material ceilings for this buyer are: first, tolerance rules are enforced at the total PO amount level only (percentage or static dollar), not at the configurable line-item price variance or quantity variance level required by the specification, meaning subtle per-line discrepancies within the total can pass undetected. Second, a failed match does not trigger automated exception routing to a designated resolver; it creates a hard-stop draft state that requires manual intervention to edit the PO or invoice, with no structured queue or assignee routing, which at 1,850 invoices per month will create an unmanaged exception backlog.

Buyer requirement: The system must support exception handling and automated routing for the approximately 1,850 PO-backed invoices per month that fail 3-way match tolerances, notifying the appropriate receiving or procurement contact (not AP) to resolve the receipt or quantity discrepancy, and holding the invoice from payment until resolution is confirmed; this prevents AP staff from acting as the manual intermediary for receipt confirmation disputes, which is a primary driver of the current 5-FTE headcount.

This buyer processes roughly 1,850 PO-backed invoices monthly and needs the system to automatically detect 3-way match failures and route those exceptions directly to the receiving or procurement contact, bypassing AP, while holding payment until resolution is confirmed. Ramp's 3-way match for NetSuite works as follows: once a bill is linked to a NetSuite PO, Ramp automatically fetches associated item receipts from NetSuite and surfaces which billed line items have not yet been received directly on the bill screen; as documented in Ramp's support article '3-Way Match with Ramp Procurement,' the AP user or admin can view unmatched receiving status and drill into item receipts. Ramp's Overbilling Protection adds a payment-hold mechanism: when an invoice exceeds the configured tolerance threshold, a draft bill is created but bill submission is blocked, and the only paths forward are editing the PO amount or editing the invoice amount. However, the automated exception routing step this buyer requires, specifically the system detecting a receipt or quantity discrepancy and then automatically notifying the receiving or procurement contact (not AP) to resolve it, is not documented in Ramp's help center. The Bill Pay approval engine routes to roles such as PO Owner, Department Owner, or Vendor Owner based on configurable conditions, and a buyer could configure a rule that sends a discrepant bill for approval to the PO owner; but this is an approval routing mechanism, not a purpose-built exception-resolution workflow that distinguishes a match failure from a standard approval step, captures resolution confirmation, and automatically releases the hold once receipt is confirmed.

Limitations: Ramp surfaces receiving status visually on the bill and blocks payment via Overbilling Protection when amounts are out of tolerance, but there is no documented automated exception routing that proactively notifies the receiving or procurement contact of a quantity or receipt discrepancy and then holds payment pending a structured resolution confirmation; this means AP staff would still need to manually triage match failures and coordinate with receiving or procurement, which is precisely the workflow this buyer is trying to eliminate. Additionally, item receipts created inside Ramp cannot be synced back to NetSuite, creating a data-integrity gap for buyers whose receiving records must live in NetSuite as the system of record.

Buyer requirement: The system must support 3-way matching of purchase order, receipt confirmation, and invoice for goods and subcontractor-based transactions in construction, where receipt confirmation is captured as a project manager or superintendent contribution within the pre-processing workflow rather than assumed from a warehouse scan. 2-way matching that skips receipt confirmation is insufficient for a construction environment where work confirmation comes from field personnel, not a receiving dock.

For this multi-location construction company on NetSuite, BILL does offer 3-way matching capability: BILL customers who use Sage Intacct and Oracle NetSuite have the ability to sync purchase orders and automate two-way and three-way matching. The matching workspace gives a complete view of purchase order, item receipt, and invoice details; BILL displays all POs associated with a vendor, populates line items and quantities from the PO, and for three-way match users, item receipt quantities populate for goods marked received in the connected accounting system. The critical architectural constraint for construction is where the item receipt originates: item receipt quantities for three-way match users populate from goods marked received in QuickBooks Desktop, and the same applies to NetSuite, where the receipt must already exist as an Item Receipt transaction in NetSuite before BILL can read it. BILL has no mechanism for a project manager or superintendent to originate a work-confirmation contribution inside BILL's own pre-processing workflow. The receipt leg is passive data pulled from the ERP, not an active field-personnel contribution captured mid-flow. This means the construction buyer's core requirement, having a PM or superintendent confirm receipt of subcontractor work or materials as a named step in the pre-processing chain, is not met: the receipt must be entered into NetSuite first by someone with ERP access, and only then does BILL's 3-way match register it.

Limitations: BILL's 3-way match depends on item receipts pre-existing in NetSuite as discrete transactions; it provides no field-facing input path (email, mobile, or Teams contribution) for a PM or superintendent to originate a work confirmation inside the BILL workflow itself. For a construction environment where 'received' means a field person confirms subcontractor work or material delivery on a job site, this passive receipt-pull architecture leaves Stage 4 of the pre-processing journey unresolved within BILL and pushes that confirmation step back into NetSuite, requiring field users to have ERP access they almost certainly will not have.

Buyer requirement: The system must execute automated three-way match across the NetSuite PO, the goods receipt record captured via req_3, and the vendor invoice, without requiring manual reconciliation. Match results must be written back to NetSuite so that PO, receipt, and invoice line items are linked at the NetSuite record level, preserving audit lineage inside the ERP rather than only inside the procurement tool.

This distribution company's core problem is that item receipts never get logged, so three-way match is impossible. BILL's mechanism works as follows: BILL syncs PO and item receipt details directly from NetSuite, and once those records exist, 2- and 3-way PO matching automatically syncs back into NetSuite to prevent errors and overpayments. The BILL blog confirms that BILL customers who use Oracle NetSuite have enjoyed the ability to sync purchase orders and automate two-way matching and three-way matching, with PO and receipt details for three-way match users syncing directly from the accounting software, with item receipt quantities updating automatically in BILL when items are recorded as received. Critically, however, the data flow runs NetSuite to BILL: the purchase order record only exists in Oracle NetSuite and cannot be viewed in Bill.com, and the BILL help center FAQ confirms that item receipts must first exist in NetSuite before BILL can consume them for three-way matching. BILL does not originate or write item receipt records back to NetSuite; it reads them. For this buyer, whose entire problem is that nobody creates receiving records, BILL's three-way match is inert unless that upstream receipt entry problem is solved through a separate mechanism. On the writeback side, 2- and 3-way matching is automated and payments are applied to the matching bill in NetSuite, enabling faster reconciliation with complete remittance information for every transaction, but a known fragility exists: editing line items for bills in Bill.com will unlink the bill from the PO in Oracle NetSuite, which can break the audit chain at the NetSuite record level. Additionally, BILL does not support linking a bill to multiple POs within Bill.com, limiting coverage for orders fulfilled across multiple receipts.

Limitations: BILL's three-way match is entirely dependent on item receipt records already existing in NetSuite; BILL does not proactively prompt requesters to confirm receipt nor does it write item receipt transactions back to NetSuite, meaning this buyer's receiving gap is not closed by BILL and the three-way match feature remains inactive for their PO-heavy, receipt-sparse environment. Editing bill lines in BILL can also silently break the PO-to-bill linkage in NetSuite, undermining the audit lineage requirement.

Buyer requirement: The vendor must provide demonstrable evidence, through references or case studies from distribution or similarly PO-heavy industries, that their tool has closed a receiving gap comparable to the one described: organizations where employees were not recording receipts and three-way match was nonfunctional, and where the tool's proactive receipt confirmation workflow measurably increased receipt capture rates. This is a vendor evaluation criterion, not a configuration requirement, and is specifically scoped to operational procure-to-pay, excluding strategic sourcing, RFQ, or supplier onboarding capabilities.

This buyer's core problem is that warehouse and receiving staff are not recording goods receipts in NetSuite, so three-way match never executes. The evaluation criterion asks specifically whether BILL has published case studies or references from distribution or similarly PO-heavy organizations documenting that problem and a measurable improvement in receipt capture rates after deployment. BILL's published case studies — spanning tech startups, beauty brands, accounting firms, and nonprofit organizations — do not include distribution or inventory-heavy buyers, and none document a scenario where employees were failing to record receipts and the tool's proactive workflows closed that gap. The one inventory-adjacent testimonial found (Polystone Planters) is a brief quote about PO matching confirming inventory accuracy, not a documented case study with before/after receipt capture metrics. BILL's three-way matching mechanism itself depends on receipt records being pre-populated in the source ERP (NetSuite, QuickBooks Desktop, Sage Intacct) and synced into BILL — meaning BILL does not contain a proactive receipt-confirmation workflow that would generate the behavioral change needed to close this buyer's specific receiving gap in the first place.

Limitations: BILL's three-way match is passive: it consumes receipt records already entered in NetSuite rather than prompting employees to confirm goods arrival, so it addresses the matching step but not the upstream receipt-capture failure this buyer faces. No public case study evidence exists of BILL closing a comparable receiving gap in distribution or a PO-heavy industry.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a distribution company on NetSuite whose three-way match is currently broken, BILL offers a Link-Review-Approve flow: when a vendor submits an invoice, the AP user links the correct PO, and the reviewer goes over items, prices, received quantities (for three-way match), and BILL alerts if there are variances. Once matching is complete, the bill is automatically sent through the payment approval workflow, with automated approval workflows preassigned by the administrator. A third-party analysis comparing BILL's PO workflow capabilities notes that BILL does support invoice approvals, but it is not designed for complex workflows: you cannot route approvals based on department, project, or vendor, and you cannot set rules for who approves what. One aggregated comparison source does credit BILL with automated 2-way and 3-way matching across invoices, purchase orders, and receipts, with configurable tolerance limits, but BILL's own help documentation and feature blog provide no mechanism description for percentage-based tolerance thresholds, tiered escalation by variance type or magnitude, or a side-by-side diff view identifying exactly which of the three documents diverges. BILL's three-way match receipt population is also documented only for QuickBooks Desktop: item receipt quantities for three-way match users populate for goods marked received in QuickBooks Desktop, leaving the receipt-leg integration for NetSuite less clearly supported within BILL's own matching engine.

Limitations: The buyer's requirement for configurable tolerance thresholds that auto-approve minor variances, plus named-handler routing with document-level variance attribution (showing exactly which of PO, receipt, or invoice diverges and by how much), is not evidenced in BILL's own product documentation; variance alerts and administrator-preassigned approval chains exist, but the rule-based, context-rich exception escalation logic the buyer needs appears to sit outside BILL's current AP workflow capabilities. Additionally, BILL's receipt-leg of three-way match is only documented for QuickBooks Desktop, raising a material question about whether true three-way match (not two-way) can be executed inside BILL for this NetSuite-based buyer.

Buyer requirement: The system must support two distinct matching regimes operating in parallel: 2-way matching (PO plus invoice, no receipt required) for service invoices, and full 3-way matching (PO plus goods receipt plus invoice) for inventory purchase orders. Each regime must support configurable tolerance rules and route exceptions to the appropriate reviewer without collapsing both invoice types into a single matching path.

This buyer needs two matching regimes running in parallel on the same AP queue: 2-way (PO plus invoice, no receipt) for service invoices and 3-way (PO plus item receipt plus invoice) for inventory POs, each with independent tolerance rules and exception routing. BILL does support both matching types, confirmed by its own product announcement: BILL customers who use Sage Intacct and Oracle NetSuite can sync purchase orders and automate two-way matching and three-way matching. The mechanism is described as a single organization-level enable decision: once you enable two-way or three-way match, BILL will sync information to support matching between the required documents. This is the critical gap for this buyer. BILL's published workflow treats matching as a single global setting, not a per-invoice-type classification gate. The blog explicitly frames the choice as a business decision between modes rather than a simultaneous dual-regime configuration: determining the type of matching that's right for you will depend on your business and what you're purchasing; many service-based businesses use two-way matching to process invoices for services, while more complexity is introduced for businesses that deal with large amounts of inventory. For exception routing and approval policies, BILL's API documentation shows that the primary policy condition is dollar amount: an approval policy is created with an amount threshold, and the approverNotSameAsPayer field can be set for additional scrutiny. There is no documented condition key for invoice type, PO category, or match-type that would route a 2-way exception to a different reviewer queue than a 3-way goods-receipt variance. The platform covers stages 2 (PO match) and partially stage 4 (receipt confirmation via ERP-synced item receipts) of the pre-processing journey, but it does not provide the workflow branching logic that selects matching templates at runtime based on invoice classification.

Limitations: BILL cannot enforce two parallel, independently configured matching paths on the same invoice stream: the matching mode operates as a single organization-level setting, meaning the buyer would have to collapse all invoices into one regime or manually segregate them outside the system. Exception routing is keyed to dollar amount, not match-type, so 2-way PO discrepancies and 3-way goods-receipt variances would land in the same approval queue rather than routing to distinct reviewers, directly breaking the buyer's stated control requirement.

Buyer requirement: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For an 8-entity real estate portfolio on NetSuite needing line-item 3-way matching with per-entity tolerance rules, BILL's mechanism fails at multiple stages of the pre-processing journey. BILL does offer 3-way matching between PO, item receipt, and invoice, but its own press release confirms this capability is delivered by syncing item receipt data from QuickBooks Desktop: BILL customers using QuickBooks Desktop can view purchase orders and match invoices, with PO and receipt details synced from QuickBooks Desktop to automate two-way and three-way matching. Because this buyer is moving to NetSuite as their ERP, not remaining on QuickBooks Desktop, the documented receipt-confirmation gate does not apply. Even on BILL's product page, the matching description covers only automating 2- and 3-way matching, checking invoices against POs and receipts to reduce errors and cut manual work, with no documentation of configurable tolerance thresholds or automated exception routing to a designated approver on mismatch. An independent analysis confirmed the gap directly: BILL does not support automated 3-way matching between purchase orders, invoices, and receipts; you can attach a PO number to a bill, but it will not check if items were received or if invoice details match the original PO, and matching must be done manually or outside of BILL. On the pre-processing journey, BILL operates at stage 2 at most (PO number linkage), but does not enforce stage 4 (receipt confirmation as a blocking gate) for NetSuite-connected workflows. There is also no evidence of per-entity configurable tolerance bands across the 8 entities; BILL manages multiple entities under one login but each has its own separate workflow, requiring separate vendor and approval rule setup per entity, which can become operationally complex.

Limitations: BILL's 3-way matching receipt gate is architecturally dependent on QuickBooks Desktop item receipt data, making it inapplicable to this buyer's NetSuite environment. Even if the QuickBooks Desktop dependency were resolved, there is no documented mechanism for per-entity configurable tolerance rules, automated exception routing to a designated approver at point-of-variance, or a hard blocking gate that prevents invoice advancement until a goods receipt or work order completion confirmation is recorded, all of which are critical controls for construction and vendor work order invoices across 8 real estate entities.

Buyer requirement: The system must support 3-way matching of purchase order, receipt confirmation, and invoice for goods and subcontractor-based transactions in construction, where receipt confirmation is captured as a project manager or superintendent contribution within the pre-processing workflow rather than assumed from a warehouse scan. 2-way matching that skips receipt confirmation is insufficient for a construction environment where work confirmation comes from field personnel, not a receiving dock.

For a multi-location construction company on NetSuite needing receipt confirmation from field personnel rather than a warehouse dock, AvidXchange's AvidInvoice module explicitly supports both 2-way and 3-way matching: AvidInvoice supports 2-way (PO and Invoice) and 3-way matching (PO, Invoice and Receipt). The construction-specific AvidSuite product page names this directly: match invoices against POs and receipts (3-way match) as a listed capability. The AvidBuy/TimberScan Purchase module extends this into the procurement side, with TimberScan Purchase enhancing procurement-related tasks including receiving, inventory management, and PO requests and approvals. However, across all documented sources, the 'receipt' leg of the 3-way match is consistently framed as a pre-existing document (packing slip, goods receipt note, order receipt) that the system matches against, not as a live workflow contribution routed to a field user for active confirmation: after completing PO review, you must compare the order receipt to the invoice and purchase order, and you should have a packing slip that also confirms the services rendered, the cost, and the quantities. There is no documented mechanism in which a PM or superintendent receives a routed workflow step to enter or attest receipt confirmation inside the AvidXchange pre-processing flow, as distinct from a back-office document match. The construction-specific workflow routing in TimberScan does support automatic routing to the appropriate approvers based on various criteria, such as role, vendor, job, commitment, and more, which means a PM can be routed an invoice for approval, but routing an approver to confirm receipt as a structured contribution is architecturally different from what is documented.

Limitations: The material ceiling for this buyer is that AvidXchange's 3-way match is a document-matching control, not a receipt-confirmation workflow step: the system expects a receipt document to already exist and matches against it, rather than routing the receipt confirmation question to a field-side PM or superintendent as an active pre-processing contribution. For subcontractor-heavy construction transactions where work confirmation comes from field personnel and no packing slip exists, this model requires the receipt record to be created externally before the match can run, which reintroduces the manual coordination gap the buyer is trying to eliminate.

Buyer requirement: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For an 8-entity real estate portfolio processing construction invoices and vendor work orders, AvidXchange's AvidInvoice and AvidBuy modules together support 3-way matching across all three documents. AvidInvoice supports 2-way (PO and Invoice) and 3-way matching (PO, Invoice and Receipt). POs can originate inside AvidBuy or be imported from an external ERP, covering stage 2 of the pre-processing journey: purchase orders can either be created within AvidBuy or imported from your integrated ERP, accounting system or third-party solution directly into the system. Stage 4 receipt confirmation is a native step: the eLearning curriculum explicitly includes 'Create a receipt from an order in AvidBuy' and 'Prepare your organization for utilizing 2 and 3-way matching by understanding permissions and details related to match policies' as discrete training objectives, indicating receipt creation and match policy configuration are built-in platform concepts. The matching engine checks documents comparatively: automated 3-way matching in accounts payable is an internal control process that helps you compare item details line by line and make sure the totals are matching up between purchase orders, receipts, and invoices. When a variance is detected, invoices must satisfy matching tolerances; if they don't, a hold is placed on the invoice and payments cannot be rendered until the hold is released or resolved, operating as a fail-safe that prevents payment of an unmatched and unverified order. Tolerance thresholds are acknowledged as a configurable concept: AP departments that use automated invoice matching can set up a threshold for tolerating mismatches. However, no technical documentation found from any source confirms that tolerance rules can be scoped independently per legal entity, nor that exception routing is automatically triggered to a designated entity-level approver at the moment of variance detection rather than requiring AP team triage from a general exception queue.

Limitations: The critical gaps for this buyer are per-entity tolerance scoping and automatic exception routing: no documented mechanism confirms that each of the 8 entities can carry its own distinct tolerance bands, or that a variance on a commercial construction invoice automatically routes to the responsible property-level approver without manual queue intervention. For a real estate portfolio where high-risk construction invoices require tighter controls than routine residential maintenance invoices, the absence of per-entity tolerance differentiation is a material ceiling.

Buyer requirement: The system must execute 3-way matching (PO plus goods receipt confirmation plus invoice) on the approximately 1,850 PO-backed invoices processed each month, with configurable tolerance rules for quantity and price variance, and automated exception routing when a match fails; 2-way matching that bypasses receipt confirmation is insufficient and must not be accepted as compliant with this requirement. This directly addresses stages 2 and 4 of the pre-processing journey for the PO-backed invoice stream.

For a buyer processing roughly 1,850 PO-backed invoices per month on NetSuite, AvidXchange offers 3-way PO matching through its AvidSuite for NetSuite product, which combines the AvidInvoice and AvidBuy modules. The AvidSuite for NetSuite page explicitly states 'full-service invoice and payment processing, including 2- and 3-way PO matching' with streamlined approval workflows and anytime access. The AvidBuy product page confirms the capability: 'Reduce the likelihood of fraudulent or incorrect invoices by leveraging 2-way or 3-way matching, placing you in complete control of your purchasing process.' AvidXchange's own FAQ confirms 'AvidInvoice supports both a 2- and a 3-way match' and that 'purchase orders can either be created within AvidBuy or imported from your integrated ERP, accounting system or third-party solution directly into the system.' On tolerance rules, AvidXchange's blog explains that AP departments using automated invoice matching can 'set up a threshold for tolerating mismatches,' and that invoices outside the configured tolerance are automatically flagged for manual review. However, the critical gap for this buyer is stage 4 of the pre-processing journey: receipt confirmation. AvidXchange's available documentation does not clearly specify whether its matching engine pulls confirmed Item Receipt records from NetSuite in real time via the API integration, or whether receipt confirmation must be entered or acknowledged separately within the AvidXchange platform itself. The API integration 'connects the two solutions and enables the sharing and syncing of data from one to the other, including invoice images and expense line items', but GRN or Item Receipt records are not named among the synced data. Furthermore, the configurable tolerance rules described in AvidXchange's content appear to be conceptual category guidance rather than documented, buyer-configurable settings within the AvidXchange matching layer itself; the detailed tolerance and exception-state configuration documented by Oracle resides in NetSuite's native 3 Way Match Vendor Bill Approval Workflow, not in AvidXchange's pre-processing layer.

Limitations: The material ceiling for this buyer is receipt confirmation integrity: if AvidXchange's 3-way match pulls Item Receipt status from NetSuite's confirmed GRN records in real time, stage 4 of the pre-processing journey is covered; if it does not, the system effectively executes a 2-way match with a receipt acknowledgment step that may rely on manual confirmation rather than a closed-loop system signal from NetSuite, which the buyer's requirement explicitly disqualifies. Additionally, the depth and location of configurable tolerance rules (within AvidXchange's layer vs. requiring configuration inside NetSuite's native SuiteApp workflow post-handoff) is undocumented in available sources and must be confirmed during a technical discovery call.

Buyer requirement: The system must support exception handling and automated routing for the approximately 1,850 PO-backed invoices per month that fail 3-way match tolerances, notifying the appropriate receiving or procurement contact (not AP) to resolve the receipt or quantity discrepancy, and holding the invoice from payment until resolution is confirmed; this prevents AP staff from acting as the manual intermediary for receipt confirmation disputes, which is a primary driver of the current 5-FTE headcount.

For a buyer running ~1,850 PO-backed invoices per month through a 5-FTE AP team, AvidXchange's NetSuite integration (AvidSuite for NetSuite) explicitly includes 2- and 3-way PO matching with invoice holds: full-service invoice and payment processing, including 2- and 3-way PO matching, streamlines approval workflows with anytime, anywhere access. When a 3-way match failure occurs, AvidXchange applies tolerance thresholds and enforces a hold: invoices must satisfy matching tolerances; if they don't, a hold is placed and payments cannot be rendered until the hold is released or resolved — a held invoice operates as a fail-safe preventing payment of an unmatched order. The platform routes exceptions into configurable queues: automated workflows catch exceptions faster and more reliably than manual checks; if the system finds mistakes, the document is forwarded as an exception and electronically routed to people and business units based on rules set up in the AP software. AvidXchange's eLearning documentation confirms the platform has dedicated exception queues and workflows managed by portal administrators. However, the documented routing model targets financial approvers and AP-configured roles: exceptions are flagged for further review within the software or resolution by accounting. The workflow engine can be configured to include non-AP roles (e.g., a procurement or receiving user assigned to an exception workflow), but AvidXchange does not document a purpose-built mechanism that maps match failure type (quantity discrepancy, missing receipt, price variance) to specific non-AP resolver personas such as warehouse receivers or procurement owners, nor a resolution confirmation gate that requires the operational resolver to log receipt confirmation before the invoice re-enters the payment queue. The gap is specifically at stage 4 of the pre-processing journey: receipt confirmation routed directly to the operational receiver, not AP.

Limitations: AvidXchange's exception routing is AP-centric by default: the platform routes match failures to configurable approval roles, but no documented mechanism automatically identifies the receiving or procurement contact responsible for a specific PO discrepancy and notifies that person directly without AP acting as the routing intermediary. Buyers who need the system itself to bypass AP and drive resolution with operational stakeholders will need to build that routing configuration manually, and there is no documented resolution-confirmation gate that holds payment until a non-AP receiver logs acceptance of the receipt.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M multi-location services company running 55% PO-based invoices through Sage Intacct, Brex Bill Pay covers the invoice-to-PO layer of matching (stage 2 of the pre-processing journey) but stops before stage 4 (goods receipt confirmation). When an invoice arrives in Brex, its AI engine reads line-item data and attempts to match the imported invoice to an open PO pulled from the connected ERP: as the Brex bill pay automation page states, 'Brex AI will also match your imported invoice to an open PO in your ERP via our two-way accounting integrations.' AP managers can also manually select from open POs surfaced by vendor, PO number, date, and remaining amount. What Brex markets as its matching capability for bill pay is explicitly two-way: the vendor's own product copy describes 'automated invoice capture, line itemization, bill drafting, PO matching, and multi-level approvals' with no goods receipt confirmation step. No Brex help center article or product documentation describes a mechanism that ingests goods receipt records from Sage Intacct (or any source) and cross-references them against the invoice as a required pre-approval gate. The Sage Intacct integration is documented as a one-directional sync from Brex to Sage Intacct for bill data; goods receipt or receiving module data from Sage Intacct is not pulled back into Brex for a three-way comparison. There is also no documented mechanism in Brex's bill pay product for configuring separate numeric tolerance thresholds for price variance versus quantity variance at the line level.

Limitations: Brex's matching stops at two-way (invoice-to-PO): goods receipt confirmation, which is the defining element of three-way matching and is critical for this buyer's facilities, supplies, and subcontractor spend, is not part of the Brex bill pay engine. Separately, no configurable tolerance thresholds (the buyer's required 2% price / 5% quantity) are documented as a Brex product feature, meaning out-of-tolerance variances cannot be automatically adjudicated or escalated by rule.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

This $120M multi-location services company needs a three-way match engine that reconciles vendor invoices against both POs and goods receipts, with buyer-configurable price and quantity tolerances, across 55% of its 1,800 monthly invoices. Brex's bill pay module reaches only stage 2 of the pre-processing journey: PO matching. Brex's own help center documents the feature explicitly as 'Matching bills to purchase orders (2-way match),' and Brex's product marketing confirms that 'Brex AI will also match your imported invoice to an open PO in your ERP via our two-way accounting integrations.' Brex's Managing Purchase Orders help article labels the capability as 'Matching bills to purchase orders (2-way match)', and Brex AI matches an imported invoice to an open PO in the ERP via two-way accounting integrations. Goods receipt confirmation, which is stage 4 of the pre-processing journey and the critical third leg for the buyer's facilities, supplies, and subcontractor invoices, is absent from the documented matching workflow. Third-party analysis notes that 'Brex users sometimes note missing AP features, consistent with the documented lack of PO/3-way support.' No help-center article or product documentation describes buyer-configurable price or quantity tolerance thresholds, making the specific 2%/5% tolerance requirement also unmet.

Limitations: Brex stops at 2-way match (invoice-to-PO) with no native goods receipt confirmation step, which means the buyer's facilities, supplies, and subcontractor invoices (the majority of their PO-backed volume) would pass payment without verifying actual delivery. Third-party reviewers characterize Brex's AP capabilities as 'bolted-on rather than purpose-built' and note it 'offers basic matching capabilities compared to specialized AP solutions.' There is no documented mechanism for configurable price or quantity tolerance bands (2%/5% or otherwise) in Brex's bill pay matching workflow.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M services company with 55% PO-based invoices covering facilities, supplies, and subcontractors, the matching ceiling matters directly for roughly 990 invoices per month. Brex's bill pay module performs automated two-way PO matching: when an invoice arrives, the AI scans it and attempts to match it to an open PO synced from the ERP, surfacing the PO number, date, and remaining available amount for AP review; if no automatic match is found, it presents the open POs for that vendor for manual selection. Brex AI matches the imported invoice to an open PO in the ERP "via our two-way accounting integrations," framing the mechanism explicitly as two-way. Brex customers "rely on PO matching to help prevent fraud and automate compliance"; if no match is found automatically, Brex displays open POs for manual selection. This covers Stage 2 of the pre-processing journey (PO match) but stops there. No product documentation, help center article, or feature page found in any search confirms that Brex's bill pay module incorporates a goods receipt confirmation step as a third document in the match, meaning Stage 4 (receipt confirmation: did we actually receive the goods?) is not handled by the system. Brex's own AP automation content describes the automated check as two-way matching that "automatically compares invoice details against purchase orders to verify accuracy," checking quantities, prices, and terms, and flagging discrepancies for review. Separately, no source documents that Brex exposes buyer-configurable tolerance thresholds (such as the buyer's required 2% price, 5% quantity bands) that determine whether a variance auto-approves or routes to an exception queue.

Limitations: Brex's matching architecture is two-way (invoice to PO) with no documented goods receipt confirmation as a native third leg, leaving the buyer exposed to paying for undelivered or short-shipped goods on their facilities, supplies, and subcontractor invoices without a warehouse or project team sign-off step in the system. Buyer-configurable price and quantity tolerance thresholds (the required 2%/5% bands) are not documented as available settings in Brex's bill pay matching engine, meaning variance handling rules cannot be tailored to the buyer's specific risk thresholds.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M services company running 1,800 invoices per month across two Sage Intacct entities, Zip's Procure-to-Pay module covers pre-processing stages 2 through 4 (PO match, terms verification, and receipt confirmation) within a single platform. Because Zip originates POs natively from approved purchase requests, the invoice, PO, and receiving information all live in the same system by the time a vendor bill arrives. Zip's Invoice Review Agent "surfaces duplicates, purchase order tolerance breaches, and contract mismatches before anything reaches an approver, with three-way matching running against contract data already in Zip." Zip's AI agents are described as performing "multi-way matching with tolerance reasoning" and resolving format variations, with the same description appearing in Zip's AI P2P product blog. Invoices that fall outside tolerance are held and routed to the right person: "Exception Automation AI places problem invoices on hold, routes them to the right person with a specific task and releases them when it's done." On the Sage Intacct side, the Zip integration with Sage Intacct performs a daily sync of entities, locations, segments, and the vendor list from Sage Intacct into Zip, and Zip confirms connectivity to Sage Intacct alongside NetSuite, Oracle Fusion, SAP S/4HANA, and Workday. However, no Zip documentation found explicitly describes a configuration screen where an admin sets a 2% price tolerance and a 5% quantity tolerance as two independently named and separately valued thresholds; the documentation describes "tolerance reasoning" and "PO tolerance breaches" as concepts without detailing the configuration interface or confirming that price and quantity tolerances are independently settable. Additionally, for the buyer's PO-based invoices whose goods receipts may be recorded in Sage Intacct's native receiving module rather than originated through Zip's intake flow, the specific data pathway that carries those Sage Intacct receipt records into Zip's matching engine is not documented in available materials.

Limitations: The buyer's requirement specifies two distinct configurable thresholds (2% price, 5% quantity); available Zip documentation confirms tolerance-based matching as a concept but does not explicitly document whether price and quantity tolerances are independently configurable as separate named fields. For any PO-based invoices where the goods receipt is recorded in Sage Intacct's receiving module outside of Zip's native workflow, the buyer should confirm during evaluation that Zip's matching engine can consume those Sage Intacct receipt records in real time rather than requiring all receipts to originate within Zip.

Buyer requirement: Automated three-way matching: PO to receipt to invoice with configurable tolerance (2% price, 5% quantity)

For a $250M technology company moving off of manual email/Slack approvals, Zip's Procure-to-Pay module (launched as 'Intake-to-Pay') does include three-way matching language in its current marketing: the system automatically matches the invoice with its corresponding purchase order and receiving information, ensuring payment only for goods and services actually ordered and received. A third-party overview of the platform confirms that Zip automates the full process by generating purchase orders instantly from approved requests, reading and matching invoices automatically, and AP tasks like three-way and two-way matching run in the background. However, the original Zip AP Automation product launch announcement described the capability as an invoice inbox and email sync, vendor portal invoice uploads, multi-language OCR and automated two-way matching with no mention of three-way matching at launch, and no help-center documentation surfaced confirming a native goods receipt confirmation module or separately configurable price and quantity tolerance thresholds (e.g., 2% price, 5% quantity as distinct parameters). Zip's most recent AP innovation announcements focus on AI Payment Risk Insights, Agentic Invoice Coding, and an Invoice-to-Contract Compliance Agent rather than tolerance-based three-way match configuration, which suggests the matching engine's configurability remains marketing-level rather than a documented precision feature.

Limitations: No vendor help-center documentation was found confirming that Zip supports separately configurable price tolerance and quantity tolerance thresholds as distinct parameters in its native matching engine; the buyer's specific requirement of 2% price and 5% quantity as independent, configurable bands cannot be confirmed as supported, and the original AP Automation launch explicitly described only two-way matching. For the buyer's $30M direct materials spend in particular, the absence of confirmed configurable separate price/quantity tolerances and a documented native goods receipt confirmation workflow represents a material gap relative to a dedicated P2P suite.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

This $120M services company runs 55% PO-based invoices across two Sage Intacct entities, making receipt-confirmed three-way matching a critical fraud and overpayment control for roughly 990 invoices per month. Airbase's dedicated AP automation module markets automated 2-way and 3-way PO matching, describing the mechanism as matching 'purchase orders, invoices, and receipts' to ensure 'every invoice is tied to the right PO and receipt with minimal manual effort.' However, the most specific technical documentation of the goods-receipt leg consistently ties it to NetSuite item receipts: a 2021 product announcement states '3-Way Purchase Order Matching: Match POs, invoices, and item receipts to ensure compliance and create a complete audit trail in NetSuite,' and an Airbase ebook repeats that 'Airbase offers 3-way matching in partnership with NetSuite.' The Sage Intacct marketplace listing confirms Airbase can 'capture invoices, create AI-powered bills, match POs, automate amortizations, schedule and send payments, auto-categorize, and sync with Sage Intacct,' but it does not reference goods-receipt matching as part of the Intacct integration. On configurable tolerances: no Airbase source reviewed documents a native, user-configurable tolerance band (percentage-based price or quantity threshold) within the Airbase interface itself; the matching engine is described generically as verifying invoices 'against pre-defined business rules,' without any settings mechanism for the buyer's specific 2% price / 5% quantity thresholds. Sage Intacct natively supports configurable match tolerances at the ERP level, but that is an ERP function, not an Airbase capability.

Limitations: For this buyer on Sage Intacct, there is no documented evidence that Airbase's goods-receipt leg of the three-way match extends to Sage Intacct the way it does for NetSuite, creating a material gap in stage 4 receipt confirmation for their PO-based invoice volume. Additionally, neither Airbase's product pages nor its help center document a native configuration interface for percentage-based tolerance bands (the buyer's 2% price / 5% quantity requirement), meaning exception routing for minor variances may require manual review rather than automatic tolerance-based clearance.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M multi-location services company with 55% PO-based invoices covering facilities, supplies, and subcontractors, this requirement goes directly to Stage 4 of the pre-processing journey: receipt confirmation before payment approval. Airbase's product pages explicitly commit to both 2-way and 3-way PO matching, stating the platform can 'match purchase orders, invoices, and receipts with automated 2-way and 3-way PO matching,' with invoice matching described as 'automating the process of matching an invoice with the corresponding purchase orders and verifying them against pre-defined business rules.' However, Airbase's own purchase order ebook notes that '3-way matching in partnership with NetSuite' is where this capability is specifically documented, raising an open question about whether the goods receipt confirmation leg of the match functions at the same depth when the connected ERP is Sage Intacct rather than NetSuite. The buyer's specific requirement of configurable tolerance thresholds (2% price, 5% quantity, separately defined) is not documented in any Airbase-authored material found; the platform references 'predefined rules and thresholds' in a Gartner quote context, but no Airbase help center article or product page specifies buyer-configurable percentage bands by dimension.

Limitations: The 3-way match with goods receipt confirmation appears most fully documented for NetSuite integrations; for Sage Intacct, the depth of goods receipt integration versus a manual confirmation step is unconfirmed, which is a material gap for the buyer's facilities, supply, and subcontractor invoice volume. Separately, Airbase publishes no documentation confirming that tolerance thresholds (price vs. quantity) are independently configurable by the buyer at specific numeric percentages, which is the operative control the buyer needs.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a multi-location services company processing 1,800 invoices per month with a 55% PO-based mix across facilities, supplies, and subcontractors, SAP Concur Invoice's PO Invoice module does support three-way matching: the system compares the invoice against an imported PO and an associated goods receipt record, and will auto-submit or auto-approve when all three documents align within configured tolerances. PO data is brought into Concur via FTP flat file or API, and receipt data must similarly be imported via the Receipt Import mechanism. Tolerance rules are configurable at the percentage level (for example, a 1% price threshold on a $1,000 PO flags invoices above $1,010), and both individual (one-to-one) and life-to-date (cumulative) matching rule types are available. However, a documented behavioral limitation exists: the three-way match evaluation fires only at the moment the invoice is first created in the system. If a goods receipt record arrives in Concur after the invoice is already in the workflow (a common scenario when invoices arrive before goods are delivered), the system does not automatically re-evaluate the pack slip match against the newly imported receipt. Users have confirmed this is by design, and SAP Concur support has indicated there is no configuration option to re-trigger the evaluation, meaning AP staff must manually intervene for late-receipt scenarios. The mechanism covers pre-processing stage 4 (receipt confirmation) in principle, but the timing constraint creates a gap in straight-through processing for any PO-based invoice that arrives before the corresponding goods receipt is posted.

Limitations: For this buyer's facilities, supplies, and subcontractor invoices, which frequently arrive before goods are physically received and logged, the one-time evaluation at invoice creation means the three-way match will not automatically clear when the receipt is later imported; manual rework is required for those invoices, partially offsetting the automation benefit on the 55% PO-based volume.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

For a $120M services company processing 1,800 invoices per month across two Sage Intacct entities, AppZen's Autonomous AP platform handles the invoice-to-PO side of matching: its AI agents use contextual understanding rather than rigid lookup tables to predict which PO lines correspond to which invoice lines, including cases where descriptions differ or line items are out of order, and can apply multiple POs to a single invoice or match multiple invoices against one PO. The platform also claims to validate pricing and flag exceptions within the PO-matching workflow. However, AppZen's publicly documented matching capability centers on PO-to-invoice comparison. The third leg of a full 3-way match, receipt confirmation from a goods receipt or receiving report, is not documented in AppZen's primary or supporting product materials as a native, system-integrated step: the company's own blog post on the subject positions its proprietary 'Star Match' as going beyond the three-way match by pulling in external signals such as badge access and shipping documents, but does not document a standard goods-receipt confirmation mechanism integrated into the AP workflow. For the buyer's 55% PO-based invoices (facilities, supplies, subcontractors), the absence of a documented goods-receipt confirmation step means AppZen covers pre-processing stages 1 and 2 (legitimacy and PO matching) but leaves stage 4 (receipt confirmation) unaddressed within the platform. Separately, AppZen's pre-built ERP connectors list Oracle, SAP ECC, Workday, and Coupa; Sage Intacct is not named in that list, which is the buyer's ERP, creating an additional integration question on top of the matching gap.

Limitations: AppZen documents PO-to-invoice line matching with customizable matching logic, but no primary or supporting source documents a native goods-receipt confirmation step (PO + receipt + invoice, with configurable 2% price and 5% quantity tolerances) within the AP workflow for Sage Intacct. The buyer would need to confirm whether receipt data from Sage Intacct's purchasing module is pulled into AppZen's match comparison or whether that leg of the match remains manual.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

This buyer runs Sage Intacct as its ERP of record across two entities, and three-way matching against POs and goods receipts is the core requirement for 55% of its invoice volume. Mekorma does not integrate with Sage Intacct at any level. Its documented ERP platforms are Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica; Sage Intacct is absent from the product entirely. Beyond the ERP incompatibility, Mekorma's product set does not include a three-way matching engine of any kind: its Invoice Capture module extracts a limited set of header fields (invoice number, date, amount, due date) and pushes them into Dynamics GP for human review, while its Payment Hub and Action Board handle payment execution and approval workflows for payment batches. None of these modules perform automated comparison of invoice line items against PO lines and goods receipt records, nor do they expose configurable price or quantity tolerance thresholds.

Limitations: Mekorma is not viable for this buyer at the most fundamental level: it does not connect to Sage Intacct, and it offers no three-way matching mechanism, configurable tolerance rules, or exception routing queue regardless of ERP. Adopting Mekorma would require the buyer to migrate off Sage Intacct to a Dynamics or Acumatica environment, and even then the matching capability the buyer needs would not exist.

Buyer requirement: Automated three-way matching: invoice to PO to goods receipt, with configurable tolerance (2% price, 5% quantity)

This buyer runs 1,800 invoices per month across 2 Sage Intacct entities, with 55% of volume PO-based across facilities, supplies, and subcontractor spend that demands receipt-confirmed, tolerance-gated matching. Mekorma has no proprietary three-way matching engine: its product scope covers payment-side automation inside Microsoft Dynamics GP and Business Central, including check run processing, payment approval workflows, vendor TIN/OFAC validation, and ACH/virtual card execution. The Invoice Capture module, its closest analog to pre-payment invoice handling, is documented as a tool for 'non-PO invoice data' that captures only invoice number, date, amount, and due date before pushing to Dynamics GP for approval routing. No goods receipt comparison, no PO line-item cross-reference, no tolerance threshold configuration (the buyer requires 2% price / 5% quantity), and no exception queue on match failure appear anywhere in Mekorma's primary or supporting documentation. Beyond the matching gap, there is a foundational ERP incompatibility: Mekorma is explicitly built for Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica; it has no integration with Sage Intacct. Deploying Mekorma would require the buyer to abandon Sage Intacct entirely, which is outside the scope of this evaluation.

Limitations: Mekorma has no three-way matching mechanism at any depth, confirmed or configurable, and does not integrate with Sage Intacct; both gaps are independently disqualifying for this buyer's requirement.