Three-way matching in AP automation

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: 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 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: 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 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: 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 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 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)

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.

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.