We are a company with 3700 invoices a month, about half are: Comparison

For a buyer processing 3,700 invoices per month with half PO-backed and 27 average coding fields on non-PO invoices, Ramp's Bill Pay module serves as the entry point via its OCR engine and AI auto-coding agent. On invoice ingestion (via email forwarding, drag-and-drop, or direct upload), Ramp's OCR technology scans and parses invoices, extracting key invoice details and automatically populating bill fields once the document lands in Drafts. Extraction covers both header and line-level data: Ramp pre-fills invoice number, due date, total, line items, vendor details, and payment details when possible. At the line-item level specifically, during invoice OCR, Ramp detects whether each line item is an 'expense' or 'item' type and adds line items accordingly, with item matching supported for NetSuite. For PO-backed invoices, if a PO number is present on the invoice, Ramp's OCR scans for it and automatically attempts to match it to an imported PO from NetSuite. The auto-coding layer sits directly downstream of extraction: using AI and historical data, Ramp's auto-coding agent sets accounting fields like GL category, location, and department on the bill and its line items, assessing line item memo and amount to associate patterns from previous bills for high-accuracy coding prediction. On the NetSuite side, Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding, and bills processed through Ramp's OCR automatically extract line items, tax information, and vendor details, then sync directly to NetSuite with GL coding and approval workflows intact, eliminating duplicate data entry while maintaining full AP controls. Ramp claims 99% OCR accuracy at the line-item level, but this is a self-reported marketing metric with no independent confidence-scoring mechanism documented in help center content.

For a buyer processing 3,700 invoices per month on NetSuite and needing line-item extraction to feed both 3-way PO matching and 27-field non-PO coding, AvidXchange's AvidInvoice module sits at Stage 1 of the pre-processing journey as the data capture entry point. AvidInvoice is described as an AI-enhanced, paperless invoice management platform that uses AI and machine learning to capture data from both header and line-item levels for accurate data entry. Invoices enter via email, scanned paper, or direct digital submission, and the full-service solution uses AI to extract critical data quickly and accurately, with indexing specialists available as an additional validation layer — meaning extraction accuracy in practice depends on a staffed human-in-the-loop model, not fully autonomous AI throughput. On the NetSuite integration side, AvidXchange's API integration with NetSuite enables the sharing and syncing of data between the two solutions, including invoice images and expense line items, which is the clearest documented evidence of line-level data transfer to the ERP. However, independent comparative analysis flags a material constraint: header-level extraction is the default in most AvidXchange modules, and line-item capture is available only in certain AvidXchange products and ERP-specific setups.

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.

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.

For this buyer's 1,850 monthly non-PO invoices on NetSuite, Ramp Bill Pay operates at stage 5 of the pre-processing journey via its auto-coding agent: using AI and historical data, Ramp's Bill Pay auto-coding agent automatically sets accounting fields like GL category, location, department, and others on the bill and its line items. The learning mechanism is per-vendor and per-field: if there are historical invoices to reference, Ramp showcases previous mappings between invoice PDF fields and accounting codes, demonstrating how it learns mappings over time; context for the auto-coding agent can be set on a per-vendor per-accounting-field basis. High-confidence coded invoices are routed to a straight-through lane: for transactions without an existing GL match, Ramp's AI codes the transaction across all required fields, and when Ramp's AI has high confidence in a coding, the transaction moves directly to the Ready to Sync tab. Corrections feed the model: upon making a change, a feedback prompt appears allowing the user to enter natural-language context as to why the change was made, and this context informs the model's learning and influences future coding decisions. On NetSuite field coverage, Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding, and the documented sync scope includes subsidiary, vendor, body-level custom fields, account, department, class, location, customer, billable status, and line-level expense custom fields. However, a documented ceiling applies to the buyer's 27-field requirement: Ramp auto-codes any field the business uses for all transactions, but does not auto-code fields like Customer or Project if they apply only to some expenses. In a 27-field coding environment, conditional dimensions such as project code, cost center, or customer job are likely among those fields, meaning they would fall outside the AI auto-coding scope and require rules-based configuration or manual entry.

This buyer processes roughly 1,850 non-PO invoices per month across an average of 27 coding fields per invoice in NetSuite, and needs AI to drive down the manual coding burden enough to reduce a 5-FTE team. AvidXchange addresses stage 5 of the pre-processing journey through its AvidInvoice platform and AI-enhanced Invoice Capture module: once an invoice is scanned into the platform, an AI is used to automatically code the invoices per the customer's specifications, searching invoice data to determine the next recipient and coding assignments. The learning mechanism is pattern-based: AvidXchange AI learns from previous invoice best practices, such as recognizing location-specific account codes and applying them to future invoices. The April 2025 Invoice Capture enhancement goes further: AvidXchange expanded the AI capabilities within its Invoice Capture feature, with additional AI capabilities that continuously learn the unique patterns of the data across invoices, delivering approval-ready invoices that reduce the need for manual touchpoints, and applying those insights to future invoices. Extraction accuracy is anchored to a measured rate: AvidXchange's purpose-built extraction algorithm, trained on millions of invoices, achieves over 99.2% accuracy, with human oversight for quality assurance and a continuously improving ML model. However, that human oversight is not limited to exception handling: AvidXchange uses AI-powered OCR and machine learning to extract and validate invoice data, providing end-to-end automation of invoice capture, coding, verification, approval, and payment processing, but relies on human indexers to verify and code captured invoice data, introducing an extra step. On the NetSuite connector, the API integration with NetSuite connects the two solutions and enables the sharing and syncing of data from one to the other, including invoice images and expense line items, and user reviews confirm the connector allows for usage of custom fields with NetSuite. The material ceiling for this buyer is that AvidXchange's coding AI is documented as ML-assisted with human indexer involvement in the standard workflow, not as a confidence-score-gated straight-through engine: no published straight-through coding rate for non-PO invoices is available, and no documentation exists confirming autonomous population of all 27 coding dimensions without human touchpoints.

For a buyer processing ~1,850 non-PO invoices per month across 27 coding fields in NetSuite, Ramp's Bill Pay auto-coding agent operates at stage 5 of the pre-processing journey (cost allocation). The mechanism is tenant-isolated: coding models are trained at the business level, learning from your specific historical coding patterns, and your data will not be used to train other businesses' models. When the auto-coding agent processes a bill, it uses AI and historical data to automatically set accounting fields like GL category, location, and department on the bill and its line items, assessing line item memo, amount, and patterns from previous bills to predict coding with high accuracy. The correction feedback loop is documented: codings are suggested based on historical coding patterns, transaction-level detail, and prior corrections; when an auto-coded field is adjusted, a feedback prompt appears allowing natural-language context, which informs the model's learning and influences future coding decisions. Confidence routing exists in binary form: Ramp's AI fills all required accounting fields using transaction context and historical coding patterns, and for every coding it surfaces the rationale and confidence level. High-confidence invoices auto-advance to Ready to Sync; low confidence appears in yellow with on-hover details showing who coded it and why. On NetSuite field fidelity, Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding, with line-level fields including account, department, class, location, customer, and line-level expense custom fields synced. Three material gaps prevent full support of this requirement: first, customers cannot set their own AI confidence threshold at this time, which limits control over what enters the touchless lane versus manual review. Second, the Accounting Agent admin guide confirms the model evaluates GL account, department, class, and location as its primary auto-coded dimensions, with conditional exclusions for fields like Customer or Project when they apply to only some invoices (documented in the AI Coding help article); coverage across all 27 of the buyer's NetSuite fields, including custom segments, is not confirmed in documentation. Third, and most critically for the FTE projection requirement, no buyer-facing accuracy lift dashboard exists. Corrections and feedback train the model, reducing future edits and increasing auto-coding accuracy over time is stated qualitatively, but there is no documented reporting interface showing week-over-week auto-approval rates, correction frequency decline curves, or per-field accuracy trends the buyer could use to project FTE reduction trajectory. The Ramp Intelligence launch referenced fields and categories that helped teams automate 20% of manual coding, but this is a cross-customer aggregate metric, not a per-tenant measurable lift curve.

For a buyer processing 3,700 invoices a month with roughly 1,850 non-PO invoices requiring coding across 27 NetSuite fields, AvidXchange's mechanism is a hybrid of AI and human indexing specialists rather than a purely algorithmic per-tenant model. The Invoice Capture enhancement announced in April 2025 states it 'continuously learns the unique patterns of the data across invoices, delivering approval-ready invoices that reduce the need for manual touchpoints' (AvidXchange AI Agents press release, April 2025). Separately, AvidXchange's AI page documents that 'our machine learning model continuously learns and improves, consistently achieving an accuracy rate of over 99.2%,' adding that 'AvidXchange AI learns from previous invoice best practices, such as recognizing location-specific account codes and applying them to future invoices' (avidxchange.com/ai-in-accounting-and-finance). However, the 99.2% accuracy figure is for data extraction validated by AvidXchange's own indexing specialists — a human-in-loop layer that sits between AI extraction and approver corrections — not a per-tenant GL coding engine trained on the buyer's specific NetSuite chart of accounts and 27-field dimension structure. The AI Approval Agent operates separately, predicting approval likelihood from historical invoice amounts and supplier details, not from GL coding patterns. No public documentation describes per-tenant model isolation, approver correction capture as a training signal for GL coding, field-level confidence scoring across a buyer-defined set of 27 dimensions, or an accuracy lift dashboard that would allow this buyer to project an FTE reduction trajectory.

For a buyer running 3,700 invoices a month on NetSuite with approximately 27 coding fields per non-PO invoice, Ramp connects via SuiteTalk REST and SOAP web services plus a custom RESTlet, pulling the live NetSuite data model into Ramp's bill coding interface on a 15-to-20-minute event-based refresh cycle. Ramp automatically mirrors the NetSuite chart of accounts, departments, classes, and custom fields, and any updates made in NetSuite appear in Ramp during the next refresh. At the field level, synced transaction fields include Subsidiary, Vendor, and body-level custom fields at the header, and Account, department, class, location, customer, Billable status, and line-level expense custom fields at the expense line. Custom segments are also supported: for each custom segment to be viewable and codeable in Ramp, the segment must be visible on the Credit Card, Bill, and/or Bill Payment Forms in NetSuite, and the Ramp Accountant Role must have full Value Management Access, Edit permissions for Record Access, and Edit permissions for Search/Reporting Access. On the AI coding side, Ramp's agent learns from past invoices and applies coding logic across hundreds of line items, and this learning operates against the buyer's actual NetSuite segment combinations pulled into Ramp. The critical qualifier, however, is that Ramp's own help documentation states it can import "most" of a customer's custom fields for bill coding, and that these custom fields function similarly to standard fields in Ramp: "most" is not "all," and the gap is unspecified. Additionally, card-level coding automation rules are only supported for single-select fields, and rules for free-text fields are not supported, indicating field-type constraints within Ramp's automation layer that may not accommodate every field type in a 27-field configuration.

This buyer needs every one of their 27 non-PO coding fields, including NetSuite custom segments, subsidiaries, and dimensions, surfaced and writable inside the AvidXchange coding layer so that posting back to NetSuite carries full dimensional fidelity. AvidXchange operates through its AvidXchange for NetSuite (AFN) SuiteApp, which is built on the Oracle SuiteCloud Computing Platform and holds 'Built for NetSuite' certification. The integration uses an API connection that, per AvidXchange's own product page, 'connects the two solutions and enables the sharing and syncing of data from one to the other, including invoice images and expense line items.' However, all available product documentation, partner implementation guides, and AvidXchange's own NetSuite solution page frame the AFN integration primarily as an embedded payment fulfillment mechanism: the documented primary value is enabling check, ACH, and virtual card payments to be executed inside NetSuite without leaving the ERP. The GL coding interface within AvidInvoice supports default GL coding rules and invoice coding workflows, and at least one user review notes that the integration 'allows for usage of custom fields with NetSuite,' but no vendor documentation, help article, or implementation guide confirms that the coding grid dynamically exposes NetSuite custom segments, subsidiary dimensions, or all user-defined fields from a live NetSuite configuration at the depth a 27-field non-PO invoice requires. The integration's field sync scope, as documented, covers standard dimensions (vendor, GL account, expense line items) and payment data, not a dynamically-discovered map of the buyer's full custom segment library.

For a company running ~1,850 non-PO invoices per month through NetSuite, Ramp Bill Pay's approval workflow builder covers three of the four mechanics the buyer requires. The builder supports multi-step, layered chains with conditions drawn from bill fields including amount, vendor, business entity, and accounting categories such as GL account, department, class, and location, allowing the coded dimensions from the non-PO invoice to drive which approver receives the bill at stage 5 of the pre-processing journey. Conditions can check bill fields including 'accounting categories' to help determine the correct approver, and approvers or groups are then added per the resolved condition. Amount-based routing is available to all customers, while GL-field and department-based conditions require Ramp Plus. Ramp Budgets supports budget-based approval workflows that enable routing to budget owners and automatic triggering based on remaining budget, displaying budget status during the approval process. Delegation on approver absence is a native feature: users can delegate an approver for their Ramp inbox when going out of the office, setting someone as their backup to unblock the team's spend, and the delegate receives approval requests on behalf of the delegator, including bills. However, the auto-escalation-on-timeout mechanic the buyer requires is not present as a hard reassignment: Ramp sends auto-reminders for bill approvals daily, Monday through Friday, with a 2-day and 3-day reminder sent to the designated approver if no action has been taken, but there is no documented mechanism that automatically reassigns or escalates the approval step to a different person after a configurable SLA window expires. Additionally, the 'Department Owner' approver role in Bill Pay is resolved from the department owner of the assigned vendor owner, not dynamically from the coded GL department field on the invoice line, which can misroute budget-owner resolution when the invoice department coding differs from the vendor owner's department. A further NetSuite-specific gap: for NetSuite Customers and Jobs, Ramp displays them in a single list, and approval chains must be manually updated for each new job, limiting dynamic GL-field-driven routing for job- or project-coded invoices.

For a company processing ~1,850 non-PO invoices per month across 27 coding fields and needing budget owners to confirm cost allocation at stage 5 without AP chasing, AvidXchange's AvidInvoice module provides configurable approval routing through a rules-and-roles engine. AvidXchange allows businesses to integrate AvidInvoice into their current workflow by letting them set customized rules for their invoice approval processes. The routing engine supports threshold-based escalation: rules and restrictions help eliminate the hassle of reaching out to an approver every month about the same dollar amount threshold, and all approval amounts can be set during implementation for a smooth, streamlined process. Role-based groups organized by department handle approver assignment: AvidXchange uses invoice workflow automation to set up approvers in groups, known as 'roles,' allowing multiple people within each role to approve the invoice without the administrator chasing down each user to figure out who it should be routed to. For absent approvers, the documented mechanism is a role-group approach rather than an automated out-of-office substitution rule: if a director is out of office and unable to approve, it is helpful to have someone else able to do so; giving permission to someone in your department to approve an invoice in their absence, and setting up these workflow permissions ahead of time, keeps the invoice moving without delay. Third-party review data confirms multi-level invoice approvals with customizable steps based on vendor or amount, with timestamped approvals and paperless workflows. The critical gap for this buyer's specific requirement is the absence of documented GL-field-driven dynamic routing: the buyer needs the routing logic to read the coded GL dimension fields (department, cost center, GL account) written during coding to automatically resolve the correct budget owner. AvidXchange's documented routing criteria center on pre-configured departmental roles, vendor identity, and dollar amount thresholds set at implementation, not on dynamically resolving an approver from the specific coded GL combination on each invoice.

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.

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.

For a buyer running 3,700 invoices per month across two invoice types and needing to track FTE displacement against a 5-person baseline, AvidXchange offers AvidAnalytics, a premium embedded BI module that sits inside the AvidSuite portal and surfaces interactive dashboards drawing on live AvidInvoice, AvidPay, and AvidBuy processing data. AvidAnalytics is described as a premium, embedded business intelligence solution offering enhanced AP reporting capabilities for AvidInvoice, AvidPay, and AvidBuy. The tool features PO, invoice, and pay data on interactive visual dashboards and allows users to drill into specific areas of interest to gain more actionable insights. One customer cited "real-time access to data" as essential, specifically referencing check payment statuses and approval metrics as use cases. An Approval Metrics dashboard is documented: AvidAnalytics includes an Approval Metrics dashboard that quantifies the average number of business days it takes for an invoice to be entered or approved. For exception-queue-based touchless rate measurement, AvidXchange's own guidance frames this as a buyer-constructed calculation: to monitor touchless processing percentage, the buyer can create a report listing invoices that went to an exception queue, then divide that count by total invoice volume. Custom dashboards are supported via a Creator License model: the AvidAnalytics Creator License allows users to differentiate between available data models and fields in order to clone, create, and save custom reports, with five standard dashboards available as a starting point. However, no documented source confirms that AvidAnalytics natively segments the STP rate between PO-backed and non-PO invoices as a pre-built dimension, nor that exception reasons are categorized at the level of specific GL coding fields (addressing the buyer's 27-field coding complexity) or by PO match failure type (price variance, quantity variance, or receipt mismatch). The touchless-rate metric is described as a derived calculation the buyer must build, not a native out-of-the-box segmented report. The supporting tier documents "intelligent reporting" and a "centralized view into your payables process," and a full audit trail with customizable workflows, which supports the existence of processing-stage log data, but the field-level exception-reason taxonomy this buyer needs is not evidenced as a native feature.

This buyer needs a live analytics layer that reports measurable STP rates segmented between PO-backed and non-PO invoices, drills into exception reasons by specific GL coding fields or match failure category, and surfaces in-flight pipeline data so they can track actual FTE displacement against their 5-FTE baseline. Ramp's documented reporting infrastructure does not deliver this. The Reporting module supports building custom dashboards tracking spend across Cards, Reimbursements, and Bills, and the Reporting Agent allows natural-language queries against spend data, but neither tool exposes STP rate as a metric, segments processing outcomes between PO-backed and non-PO invoice populations, or maps manual-touch events to specific exception reasons such as which of the buyer's 27 coding fields triggered human intervention. At the workflow level, Ramp organizes bills into stage tabs (Drafts, Approvals, For Payment, History, Overview) with filter and sort capabilities, and the approval page surfaces per-bill AI signals when a PO mismatch or pricing change is detected; however, these are operational queue views and per-bill flags, not aggregate analytics panels. The AP Aging report covers cash management (outstanding amounts by aging bucket) but contains no processing-rate or automation-rate data. No evidence was found in Ramp's help center or marketing documentation of a native STP rate KPI, exception-reason code taxonomy tied to Bill Pay, or FTE displacement measurement capability.