RFP Requirements: AP Automation (Manufacturing) ## Invoice: Comparison

For a manufacturing buyer processing invoices with complex line-item detail, Stampli's Billy AI uses OCR combined with NLP to extract invoice data automatically upon receipt, covering standard financial header fields (vendor name, invoice number, date, amounts, tax) and standard line-item fields including product descriptions, unit prices, and quantities without requiring upfront template training. Billy uses NLP to understand, extract, and classify invoice data accurately, identifying fields like vendor name, due date, amount due, and payment terms, as well as line-item information including product descriptions, unit prices, and quantities. Beyond standard fields, Stampli digitally captures invoice data via advanced OCR and AI, and Billy auto-populates fields based on accounting codes including any custom fields configured in the system. Custom field mapping is available at both header and line level: Stampli's custom field mapping capability allows mapping any field to ERP-specific fields at both the header and line levels, covering unique data requirements including custom fields, multi-currency transactions, and tax configurations. This means manufacturing-specific fields like lot numbers or heat numbers are configurable rather than pre-built named extraction targets. Accuracy improves over time: Stampli uses historical invoice data from specific vendors to improve line-item accuracy over time through supervised learning loops. However, no Stampli-authored source publishes a 95%+ extraction accuracy figure for data capture, and OCR accuracy on line items is a more nuanced issue; Stampli handles header-level fields reliably, but line-item extraction is harder because invoice tables vary widely in structure, column labels differ between vendors, and Stampli's OCR was built to support a workflow platform rather than specialize in granular data capture.

For a manufacturer processing raw material and component invoices into NetSuite, Medius Capture operates at stage 1 of the pre-processing journey: document ingestion and structured data extraction before any workflow step begins. The module combines OCR, AI, and machine learning to extract invoice data without requiring pre-built templates. Medius Capture uses OCR, AI, and ML to intuitively extract relevant data from paper and digital invoices, including PDF, e-invoices, and EDI, eliminating the need for manual checks and reviews. At the line-item level, the product page explicitly states it captures information from invoice headers and line-items, then automatically matches them against single or multiple POs and receivables. The system is template-free and self-improving: modern invoice capture tools like Medius Capture use AI and ML to improve accuracy and reduce manual work, learning from past invoices, adjusting to new formats, and processing various layouts without needing templates. A customer benchmark confirms the learning curve is short: TVH reports that usually only three invoices from a new supplier are needed for the system to learn the data format and indicate a high enough confidence level to enable automatic touchless capture. The documented standard field set covers supplier name, invoice number, date, amounts, line items, and tax. However, no public Medius documentation confirms native extraction of manufacturing-specific identifiers such as heat numbers, lot/batch numbers, or part numbers as discrete, labeled line-item fields. The vendor's headline 95% precision figure applies to the coding and matching layer, not to raw OCR extraction accuracy across the buyer's full 14-field specification.

For a manufacturing buyer whose raw material invoices routinely run to dozens or hundreds of line items across multiple pages, Stampli's Billy uses a template-free ML and OCR engine that is explicitly designed to handle multi-page invoices and performs line-by-line extraction across all line types, including GL, charges, fixed asset lines, and resources. Stampli's solution streamlines the handling of various invoice formats and efficiently manages multi-page and multi-invoice documents, simplifying workflows. After a multi-page invoice is uploaded into Stampli, the invoice can be split and pages can be deleted or re-arranged. When onboarding with Stampli, no one at Stampli writes complex code to tell Billy how to handle invoices step-by-step; through machine learning models, Billy observes millions of invoices and effectively programs itself to extract key details with increasing accuracy, continuously refining its understanding over time as it is exposed to more diverse invoice types, formats, and layouts. Stampli's own blog also uses a manufacturing scenario with "hundreds of highly detailed" line items as a reference use case, positioning Billy as the solution for GL coding and PO matching across those lines. However, no Stampli help center documentation or product specification explicitly describes the technical mechanism for cross-page table continuation, such as how column headers are inherited across page breaks, how continued table rows are stitched together, or whether any per-invoice line-item volume ceiling exists. The document management feature (split and rearrange pages) addresses page organization but is distinct from the extraction accuracy guarantee the buyer needs across those page boundaries.

For a manufacturer receiving multi-page raw material or component invoices with potentially hundreds of line items, Medius Capture is the relevant module. It operates at Stage 1 of the pre-processing journey (invoice ingestion and data extraction) using a combination of OCR, AI, and ML. Medius documents that Capture extracts both header and line-item data in a template-free manner, learning from corrections so that recurring vendor formats improve over time without explicit template configuration. The product page confirms it captures 'information from invoice headers and line-items then automatically matching them against single or multiple POs and receivables,' and the SAP Ariba companion documentation specifically states the system 'performs 3-way matches on multi-page invoices.' Invoices that fall below a configurable confidence threshold are routed to a manual validation queue rather than passed forward with unverified data. What is not documented in any available Medius source is the specific mechanism for maintaining column context and table structure continuity across page breaks in very high line-count documents: Medius does not publish details on pagination-aware table stitching, cross-page column header inheritance, or line-item volume limits per invoice. For a manufacturing buyer whose raw material invoices may span 10-15 pages with 200-400 line items, this is a material gap; the general capability is evidenced but the specific high-volume, cross-page extraction robustness is not.

This manufacturing buyer needs to extract structured technical metadata from complex invoices: engineering spec references, material certification numbers linked per line item, and tiered pricing tables with volume breakpoints. Stampli's Billy AI handles the invoice capture stage of the pre-processing journey, operating before GL coding and PO matching. Billy uses NLP and machine learning to extract line-item data, and Stampli documents that it can handle custom fields at both header and line levels, including fields mirrored from NetSuite. The intelligent system can work with custom fields, and Stampli mirrors any custom fields set up in NetSuite and can map them to be used just as the buyer does today, including bringing in results of saved searches into custom fields. At the document intelligence layer, Billy has processed transactions across manufacturing BOMs and, rather than operating from industry templates, learns the buyer's specific requirements through observation and feedback, not preset configurations. Unlike providers that rely on managed services to verify OCR, Stampli's invoice capture is fully automated, with Billy leveraging an enormous volume of training data to capture invoice data from the first invoice, without up-front AI training. However, no Stampli documentation establishes a specific mechanism for recognizing tiered pricing tables as structured pricing logic (i.e., identifying which volume breakpoint tier applies to the invoiced quantity and extracting the correct unit price accordingly). The custom field framework syncs ERP-defined fields into Stampli's interface but does not document AI that identifies and extracts novel manufacturing metadata fields like material certification numbers or heat number references from unstructured invoice document layouts. One reviewer noted that invoice scan does not pick up correct information approximately 40% of the time, suggesting further development could be helpful to detect more invoice formats.

A manufacturing AP operation receiving invoices with embedded engineering spec references, material certification cross-references by line, and tiered pricing tables sits at the hardest end of the extraction problem. Medius Capture, the vendor's dedicated ingestion and extraction module, uses an AI and ML engine trained since 2016 on hundreds of millions of invoices and explicitly markets itself as template-free: suppliers do not need to change their invoice format, and the system learns from user corrections at the 'Send to workflow' stage without requiring predefined layouts. The manufacturing vertical page documents 'detailed line-item capture and multilevel matching' for direct material POs, and the platform architecture includes configurable 'Capture Line fields' (referenced in the March 2025 Solution Overview) alongside user-defined business rules applied at the validation stage. For standard line-item fields such as item number, description, quantity, and unit price, this mechanism is well-evidenced. However, no documentation in any tier confirms: (a) configurable domain-specific extraction schemas for manufacturing metadata such as heat numbers, certification IDs, or engineering spec references at the per-line level; (b) structured tiered/volume breakpoint pricing interpretation at the capture stage, meaning the AI selecting the correct contract-tier unit price based on quantity rather than simply reading whatever printed unit price appears on the document; or (c) passthrough of certification reference fields to NetSuite or a quality system downstream. The learning engine operates at the field-connection level for known supplier formats and will generalize across layout variants, but the field schema it targets appears to be the standard AP invoice field set rather than a configurable domain-specific schema.

This manufacturer's requirement asks Stampli to automatically apply numerical conversion factors (lb to kg, drum to gallon, foot to meter) before 3-way matching executes, backed by a configurable conversion table maintained by AP or procurement admins. Three targeted searches across Stampli's help center, PO matching documentation, and NetSuite integration pages returned no evidence of any such mechanism. Stampli's PO matching layer documents tolerance thresholds, discrepancy flagging, and live PO quantity sync from NetSuite, but none of these capabilities address UOM normalization prior to matching. One Stampli blog example does describe Billy recognizing that '100 bushels of green apples' and '80 cases of apples' refer to the same line item, but this is semantic item-identity recognition, not numerical unit conversion with stored conversion factors. NetSuite natively maintains a UOM conversion table at the item master level (Lists > Accounting > Unit of Measure), but there is no evidence Stampli's AP layer invokes or surfaces that conversion engine during matching; the two systems sync quantities and PO data, but UOM reconciliation is not documented as part of that sync.

This manufacturing buyer needs automatic UOM conversion (e.g., pounds to kilograms, drums to gallons, feet to meters) applied at the moment of extraction and before 3-way matching, driven by a configurable conversion table stored in the AP platform. Medius's documented behavior is the opposite: when a vendor invoices in a different UOM than the PO, the invoice stops in the 'Analyze' step and registers as a quantity or unit-price deviation. The platform's own customer success material describes this exact scenario, where a vendor invoicing in PACKS against a PO in individual units 'causes the invoice to stop in the Analyze step in Medius with a deviation,' and the documented resolution is to adjust supplier-level match settings or ask the supplier to correct their invoice format, not to apply a stored conversion factor. The Medius AP Automation for Oracle NetSuite specification (May 2025) confirms that 'for quantity differences, no automatic coding is applied' and that businesses must resolve these variations manually. Configurable deviation tolerances (five types: header amount, line total, unit price, quantity, configurable by percentage or amount at the company or supplier level) operate as pass/fail gates on numeric deltas, not as unit-normalization logic; they cannot convert 30 pounds into 13.6 kilograms before comparing to the PO quantity.

For a manufacturing AP team receiving invoices that bundle product lines with freight, handling, tooling, and surcharge lines, Stampli operates at Stage 1 (legitimacy and capture) through Stage 2 (invoice-to-PO reconciliation). Billy extracts header and line-item data using OCR and ML, then codes each line individually, applying GL accounts and custom dimensions learned from historical coding patterns. Freight and ancillary charges that lack a backing PO line are handled through Stampli's on-invoice fee entry mechanism, which lets AP add non-PO charges directly in Stampli without returning to the ERP. The PO Matching module explicitly names taxes and freight charges as complex scenarios it handles within 2- and 3-way matching workflows, and the system supports customer-defined tolerance settings that trigger exception routing when charges fall outside accepted thresholds. For SAP-connected environments, Stampli documents unplanned delivery cost allocation that proportionally distributes unexpected delivery costs across PO lines, and imports freight, storage, and other fee types so they post correctly; however, this level of per-charge-type specificity is not confirmed in NetSuite-specific documentation, which is the buyer's actual ERP. The mechanism for tooling charges and handling charges specifically is Billy's learned GL suggestion engine and vendor-specific GL table templates, not a dedicated charge-type classification engine that categorizes freight vs. tooling vs. handling as distinct charge classes with independent tolerance rules per category.

For a manufacturing buyer whose suppliers routinely tack freight, handling, pallet, and tooling charges onto PO invoices as separate line items, Medius handles this through a dedicated 'Additional Charges' configuration module (Administration > Company > Enterprise > Additional Charges). Suppliers often include charges on invoices that are not on the purchase order; common examples are freight, environmental fees, and pallets, and if additional charges are not properly configured in Medius, those charges will result in manual processing. The configuration operates at two levels: additional charges can be configured at both the company and supplier levels, allowing general limits to be set and then customized for specific suppliers, such as a higher freight limit for certain vendors while keeping a lower limit for all others. Recognition relies on keyword or wildcard matching: the additional charge rule will connect if 'freight' appears anywhere in either the item number or the description on the invoice line. When a charge is recognized and within the configured limit, it auto-processes; when it exceeds the limit, the limit set determines if additional approval is required. GL coding for recognized charges can be auto-populated via the 'Same as Cost' (SaC) option: SaC for PO invoices automatically populates coding dimensions and tax indicators based on the purchase order. However, the MediusGo support portal confirms that surcharges on the invoice that are not on the purchase order, such as freight, packaging, and pallet fees, may require manual coding approval depending on how the purchasing system handles them. This positions the capability within stage 2 (PO matching) of the pre-processing journey: Medius intercepts non-PO charges before they cause a blanket match failure and routes exceptions to the right approver, but it does not validate charges against contracted freight rates or tooling agreements stored in a vendor master.

For a manufacturing buyer processing recurring raw material and component invoices from the same supplier pool, Billy's learning architecture directly addresses this requirement. Billy uses machine learning models that, rather than following static instructions, continuously refine extraction accuracy as invoices are processed: corrections made by AP reviewers feed back into the model, and the system progressively reduces exceptions for familiar vendor formats without requiring IT or template configuration. Stampli documents this explicitly: corrections contribute to a feedback loop applied to future transactions, and Billy adapts to each customer's operational reality through observation and feedback rather than preset configurations. The mechanism also operates at the format level: as the system processes invoices, it learns different invoice formats and internal processes to become more accurate and efficient over time, with Billy automatically suggesting coding table templates when it detects a recurring pattern from a specific vendor. This operates at Stage 1 of the pre-processing journey (legitimacy and data extraction) and feeds directly into Stage 2 (PO matching), with accuracy gains accruing across the invoice lifecycle as volume with each supplier grows.

This manufacturing buyer needs extraction accuracy on recurring supplier formats to improve passively over time as AP staff correct fields during exception handling, with no manual template configuration per vendor. Medius delivers this through two complementary mechanisms inside Medius Capture and its SmartFlow engine. First, the platform has an agentic, event-driven core that records every human action taken during invoice processing, including field-level corrections, exception resolutions, and coding overrides. Medius can see the actual events that take place in the platform, including the actions that humans have taken to correct errors, manage exceptions, and handle corner cases, and for the last 10 years has captured all these 'human in the loop' events to build a training dataset for its AI. Second, SmartFlow, a proprietary convolutional neural network, uses this correction history at the customer level and enriches it with a cross-customer dataset. Invoice coding is applied automatically by proprietary machine learning models, including SmartFlow, a proprietary CNN that reaches 95%+ coding precision after just two invoices, trained on the buyer's historical actions and enriched by 2.4 billion+ invoice field data points across Medius's global customer base; critically, over 393 million of those data points come from real-world human corrections, capturing the long-tail edge cases that generic AI models miss. The system explicitly displaces template-based approaches: Medius automates invoice processing by extracting all the data needed from supplier invoices, with AI and ML taking invoice scanning solutions to the next level without the need to maintain templates or configurations. As correction history accumulates for a given supplier format, the confidence threshold rises and those invoices progressively bypass the exception queue. SmartFlow builds confidence in recognizing patterns, with templates that can be assigned to specific suppliers ensuring consistency and reducing manual intervention; as SmartFlow matures, it increasingly automates coding decisions, allowing invoices to bypass manual review and proceed seamlessly through the approval workflow. This capability sits at Stage 1 of the pre-processing journey (legitimacy and data extraction) and feeds directly into automated 3-way matching downstream.

For a manufacturer running NetSuite with diverse commodity categories requiring different tolerance bands, Stampli delivers true 3-way matching at the item receipt level: it ingests live PO and GRN data from NetSuite on a continuous sync cycle and compares invoice quantities, prices, and amounts against both documents before any approval action is taken. 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; with support for one-PO-to-many and many-PO-to-one matching, and validation against actual received quantities rather than just PO headers. On the tolerance side, Stampli automatically skips invoice approvals when POs and invoices match based on customer-defined tolerances, and the matching process runs on predefined rules and tolerances. However, the documented evidence stops at 'customer-defined tolerances' as a concept: Stampli identifies exact matches and discrepancies using customer-defined tolerance settings, but there is no product documentation in Stampli's help center or product pages confirming that tolerance rules can be segmented simultaneously by commodity type, item class, vendor, plant, or dollar band. The blog guidance that describes vendor-specific or dollar-threshold-specific tolerance logic (e.g., 5% price difference for certain vendors on purchases under $5,000) reads as conceptual implementation advice rather than a documented configuration capability within Stampli's own tolerance rules engine. This means the 3-way match mechanism (Stage 3 and Stage 4 of the pre-processing journey: PO match and receipt confirmation) is fully handled by Stampli, but the per-commodity tolerance differentiation the buyer requires sits at an undocumented level of granularity.

For a manufacturing company running multi-commodity procurement through NetSuite, Medius's 'Connect' and 'Match' workflow stages execute true 3-way matching: the system links extracted invoice lines to PO lines and Goods Receipt (GRN) data synced from NetSuite, then identifies deviations before routing. Invoices with all deviations within tolerance bypass the 'Analyze' queue and move directly to touchless approval; out-of-tolerance exceptions route to a designated reviewer for resolution. Tolerance configuration is supported in two forms: 'connection tolerances' (which determine whether Medius auto-links an invoice line to a PO/GRN line when amounts are not an exact match) and 'deviation tolerances' (which determine whether a matched discrepancy is auto-approved or escalated). Both types support either absolute dollar amount or percentage bands, and both can be set independently for header level and line level. Critically, Medius documents tolerance segmentation at two axes: company level (a global default) and supplier level (supplier-specific settings that override the company default). The buyer's requirement, however, demands four segmentation axes: commodity type, vendor, plant, and dollar amount. Vendor-level and dollar/percentage-amount tolerances are confirmed; commodity-type and plant/receiving-location tolerance segmentation is not documented in any Medius help content or configuration guide found.

This manufacturing buyer needs four distinct tolerance profiles applied at the commodity category level: raw steel at +/- 2%, MRO at +/- 5%, and exact-match enforcement for both precision-machined components and hazardous chemicals for regulatory tracking. Stampli's PO matching module does support customer-defined tolerance settings that govern when invoices auto-approve versus get flagged: its product page states it will 'automatically skip invoice approvals if POs and invoices match, based on customer-defined tolerances,' and blog documentation describes configuring rules by vendor (e.g., accept a 5% price difference only from specific vendors) and by dollar-amount threshold. However, across Stampli's published product pages, blog corpus, and PO matching documentation, there is no evidence of a commodity-category-level tolerance rules engine that would allow raw steel, MRO, precision components, and hazardous chemicals to each carry independently configured thresholds. The tolerance configuration appears to operate at a global or vendor level, not at the item-classification or commodity-category level that this buyer requires. This means the exact-match enforcement needed for hazardous chemicals and precision components cannot be reliably isolated from the percentage-based tolerance applied to raw steel or MRO — a material gap for a buyer where regulatory tracking demands zero-tolerance behavior on specific commodity lines.

This manufacturing buyer needs four distinct tolerance profiles keyed to commodity category: raw steel at +/-2%, precision-machined components at exact match, MRO at +/-5%, and hazardous chemicals at exact match for regulatory traceability. Medius's deviation tolerance engine, configured through its 'Configure deviation tolerances' feature in the AP Automation module, supports five deviation types (header amount, line total, unit price, quantity, and tax) and allows each to be set by either fixed amount or percentage. However, the documented configuration hierarchy stops at two levels: company-wide defaults and supplier-specific overrides. Supplier-specific match settings override the company configuration, but there is no documented commodity-category or item-classification tier in the tolerance rules engine. Because a single supplier can supply both raw steel and MRO items simultaneously, a vendor-level tolerance rule cannot enforce +/-2% on steel lines and +/-5% on MRO lines from the same invoice. This is the material ceiling: the mechanism exists for global and per-supplier tolerance differentiation, but not for per-commodity-category differentiation, which is precisely what this buyer requires.

For a manufacturing buyer running high-volume routine procurement invoices through NetSuite, Stampli's PO Matching module directly addresses this requirement via a configurable approval-bypass rule. Stampli automatically skips invoice approvals if POs and invoices match, based on customer-defined tolerances. This is not a "ready to approve" notification that still parks the invoice in a queue: the approval stage is bypassed entirely for matched invoices. Stampli can be configured to skip the approval stage for invoices that match the associated purchase order exactly, which speeds up invoice processing and payment times and reduces approvers' workloads. The upstream mechanism feeding this bypass is 3-way matching: 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. Invoices that clear all three legs of the match within tolerance proceed straight to payment preparation, while exceptions route to the appropriate human reviewer. When an invoice is approved in Stampli, Stampli's NetSuite integration automatically generates a vendor bill in NetSuite with a link to the invoice in Stampli; after the vendor bill is processed and paid in Stampli, Stampli automatically generates the payment against the open vendor bill(s) in NetSuite. This closes the full loop from touchless approval through ERP posting without manual re-entry.

For a manufacturer running high-volume PO-based procurement on NetSuite, Medius delivers touchless auto-approval through two layered mechanisms. First, 'Touchless Capture' is a configurable setting: invoices that meet all high-confidence extraction criteria bypass manual verification entirely and advance directly into the matching workflow. Second, configurable 'connection tolerances' are set at the PO/GR line level so that invoices matching within defined thresholds (e.g., a small price or quantity deviation) are automatically connected and approved without entering a human approval queue. Medius's own help center confirms that 'invoices that meet all green criteria will automatically advance to the workflow,' and that tolerance rules allow the system to 'connect based on the total amount of the line, even though the amounts are not exactly equal.' Invoices that pass all matching criteria within tolerance proceed straight through to payment via Medius Payments' straight-through processing rail, with no human touchpoint required. Medius's AI Innovation page identifies 'SmartFlow' as the underlying model driving these straight-through processing rates, and the vendor publishes a 96.3% touchless rate for PO invoices vs. a 23.4% market average (Ardent Partners, 2025), covering pre-processing stages 2 (PO match) and 4 (receipt/GRN confirmation) with exceptions routed to human queues only when tolerances are breached.

A manufacturing AP team receiving a vendor invoice that groups multiple raw-material PO lines into fewer invoice lines operates in Stampli's PO matching module, which covers pre-processing stage 2 (PO match) and stage 4 (receipt confirmation via 3-way match). Billy, the embedded AI, codes invoices line by line and applies GL accounts, departments, and custom dimensions learned from historical coding patterns, then links each invoice line to the correct PO or receipt before any human review. For the specific misalignment scenario where vendor invoice lines are grouped differently than PO lines, Stampli supports one-invoice-to-many-PO matching natively: it handles 'partial shipments, split orders, or vendor consolidation invoices at the line level without requiring manual workarounds or splitting invoices,' with live PO and receipt sync from NetSuite every two hours or on demand. The NetSuite integration, which is Built-for-NetSuite verified, syncs GL accounts, departments, locations, and custom fields (including NetSuite Class, Department, and Job dimensions) bidirectionally, so each matched PO line carries its production job, work order, cost center, or project code through to the invoice line. Where Billy cannot auto-resolve a grouping mismatch, reviewers use a unified invoice-and-PO view with line-level adjustment tools to manually remap invoice lines to their correct PO lines and allocations without leaving the matching workspace. GL table templates add a second mechanism: vendor-specific allocation templates can be configured to distribute a single invoice line across multiple GL accounts or departments at defined percentages, and Billy auto-suggests templates when it detects a recurring pattern.

This buyer's scenario is a manufacturing context where a vendor's invoice may consolidate multiple PO lines (each allocated to a distinct production job, work order, cost center, or project) into a single grouped line, requiring the AP system to disaggregate and reconcile those allocations automatically. Medius operates at pre-processing stage 2 (PO matching) through a cascading Auto-Connect engine: it first attempts a precise item-code-plus-quantity match against PO line details; if that fails, it falls back to a Line Total Match comparing net amounts of individual invoice lines against PO or delivery line net amounts; and finally applies a Line Amount Connection for service-based lines. The system attempts to match at the PO line detail level for unit price and quantity validation, but if discrepancies exist such as incorrect product codes the invoice is halted for manual connection; for still-unconnected lines the system attempts a Line Total Match comparing the net amount of an individual invoice line to the PO or delivery line net amount. Critically, the structure of coding dimensions, including both standard and custom dimensions, is determined during onboarding, and Medius imports all coding dimensions directly from Oracle NetSuite, meaning job, class, department, and project fields from NetSuite propagate onto matched PO lines. Multi-invoice to multi-PO and PO line matching connects the right information from the invoice, purchase order line, contract, and goods receipt automatically. However, the documented mechanism for structural line grouping mismatches (where a vendor consolidates two or three PO lines into one invoice line, each with separate job or work order allocations) is manual resolution: for quantity differences, no automatic coding is applied; instead, businesses must resolve these variations manually by addressing delivery discrepancies. SmartFlow's AI coding engine addresses non-PO invoice coding automation, not the structural reconciliation of PO line structure to invoice line structure for goods-based invoices.

For a manufacturer tracking partial shipments across multiple delivery events on a single PO line, Medius routes the incoming invoice through its order-matching engine, which compares extracted invoice lines against delivery lines (goods receipts) synced from NetSuite via a certified SuiteApp connector. When an invoice arrives before all ordered quantities have been received, the system automatically places it in a dedicated 'Await Delivery' queue, holding it from payment progression until the missing GRN data is available: 'If an order invoice that has been imported...is found to be partial without deliveries (all item rows to which the invoice relates are not delivered), the invoice can be sent to Await delivery.' Once partial GRN data exists, the invoice moves to the 'Matching Order' queue, where it is matched against the available delivery lines at the line level, with the system displaying a 'Still to allocate' balance that must reach zero before auto-approval fires. Five configurable deviation types (header amount, line total, unit price, quantity, and others) can be set by amount or percentage at the company or supplier level, controlling whether a quantity shortfall on a partially-received line auto-approves within tolerance or routes to an exception analyst. Invoices that pass all matching criteria within tolerance are automatically approved for payment via the AllowAutoOrder system parameter, while lines with invoiced quantities exceeding received quantities are held and flagged as quantity deviations, preventing overpayment for backordered items. This covers pre-processing stages 3 (receipt confirmation) and 4 (PO matching) of the journey, and the mechanism is compatible with the buyer's end-to-end flow because partial holds are line-level rather than invoice-level, allowing fully-received lines to proceed while backordered lines remain parked.

For a manufacturing buyer dealing with raw material and component partial shipments, Stampli addresses this requirement primarily through its live NetSuite data sync layer. Item receipt records created in NetSuite flow into Stampli every two hours (or on-demand), and Billy performs 3-way matching against actual received quantities rather than PO quantities alone. Stampli's validation algorithm flags discrepancies where invoiced quantities exceed confirmed received quantities, holds those invoices in an exceptions queue before payment, and explicitly supports one-PO-to-many-invoice and many-PO-to-one-invoice scenarios including partial shipments and cross-department orders. The product page also documents the ability to 'process partial amounts' against PO lines, and the validation layer 'stops payments that don't match.' However, the critical dependency is that Stampli does not maintain its own goods-receipt ledger: the receiving team must finalize item receipts in NetSuite first, and Stampli then mirrors that data. Open PO balance tracking and backorder status live in NetSuite as the system of record; Stampli reads and enforces against them but does not independently accumulate a running received-vs-invoiced ledger. The documented mechanism is exception flagging and hold-for-review rather than a confirmed automatic line-level payment block, and granularity of holds at the individual PO line (vs. the full invoice) is not explicitly documented.

For a manufacturing buyer whose vendor invoices a full PO line quantity against receipts split across multiple plants, warehouses, or dock locations, Stampli's mechanism works as follows: Stampli syncs NetSuite item receipt records every two hours (or on-demand) and surfaces live PO receiving status inside the AP workspace. Live PO, receipt, and item-receipt data flow into Stampli every few minutes, enabling true 3-way matching, split PO scenarios, and rapid exception handling; the integration supports one-PO-to-many and many-PO-to-one matching, with true 2-way and 3-way matching to item receipts. Stampli's AI (Billy) is documented as able to understand and process complex matching scenarios such as split deliveries, reaching the same matching conclusions as human operators 97% of the time and improving continuously. The critical architectural dependency is that Stampli reads the consolidated receiving status from NetSuite rather than performing independent per-location aggregation itself: Stampli automatically syncs open purchase orders and receiving data from NetSuite every two hours and can refresh on demand; it syncs the live receiving status of POs so AP can ensure the right status to match invoices, with capabilities that include handling partial shipments and cross-departmental orders accurately. This means the aggregate received quantity presented to Stampli's matching engine reflects what NetSuite has already consolidated from all location-level item receipts tied to a PO line. Stampli supports single or multiple POs with adjustable line-level detail and real-time sync of receiving status notifications, and for NetSuite OneWorld customers, manages multiple locations, subsidiaries, currencies, and international tax calculations. This positions Stampli at stage 4 of the pre-processing journey (receipt confirmation), pulling confirmed receipts from all NetSuite locations and presenting the aggregate against the invoiced quantity before approval routing.

The buyer's scenario requires that when a vendor invoices the full quantity of a PO line that was received in partial shipments across multiple plants, warehouses, or dock locations, Medius must aggregate all site-level receipt records into a single cumulative quantity before comparing it to the invoiced amount. Medius does support full 3-way matching (PO + goods receipt + invoice) with GR data synced from NetSuite via its certified SuiteApp connector, and its matching engine operates at the PO line level, including multi-PO and multi-PO-line scenarios. The platform also surfaces GR deviation detection, including a configurable 'Show goods receipt deviation first' toggle that prioritizes missing-GR exceptions in the queue. However, no Medius documentation reviewed, including its invoice matching product pages, NetSuite integration guide, AP Top Tips help articles, or the Microsoft Marketplace listing, explicitly describes a mechanism that aggregates multiple item receipt records (each carrying a distinct NetSuite location/warehouse code) for the same PO line into a single received-quantity total before validating against the invoiced quantity. The critical gap is whether Medius treats receiving location as a non-matching dimension (transparent aggregation) or as a matching key that could generate false quantity mismatches when a vendor invoices the full line against receipts distributed across sites. Without confirmation of the aggregation behavior, there is a material risk that the engine would flag a correctly-invoiced split-delivery as a quantity deviation, requiring manual exception handling for every routine multi-site shipment.

This manufacturing buyer needs a goods-receipt-triggered payment path for enrolled ERS suppliers, where no vendor invoice is submitted and the GRN event itself creates the payable and initiates payment. Stampli's entire procure-to-pay architecture is invoice-centric: Stampli captures invoices, extracts key invoice data, applies coding, and routes them through approval workflows, then matches invoices to purchase orders and receiving records, flagging discrepancies before payment. Approved invoices can be paid directly from Stampli using supported payment methods. The initiating event is always an inbound invoice document. While Billy connects POs, receipts, and invoices in real time, performing 2- and 3-way matching and keeping ERP records in sync, this matching still presupposes an inbound invoice as the trigger. No mechanism in Stampli's documented product, help center, or public-facing materials creates a synthetic self-billing document upon GRN posting for ERS-enrolled suppliers, bypassing the invoice submission step. Four targeted searches across stampli.com and help.stampli.com returned zero results for ERS, evaluated receipt settlement, self-billing, or pay-on-receipt supplier programs.

This manufacturing buyer needs a GRN-triggered payment mechanism for enrolled suppliers: goods are received, the system generates a synthetic payable, and payment runs without any vendor-submitted invoice. Medius's entire AP workflow, across every product page, help article, and documentation source found, is structured as an invoice-led process. Invoice matching in Medius is used when a vendor invoice is preceded by a purchase order from the buying organization. The system then matches that inbound invoice against the PO and goods receipt for 3-way validation. A PO invoice is pre-approved and automatically processed for payment if the details match the PO and goods receipt, but this touchless path still requires the vendor to submit the invoice first. The invoice data (lines and headers) recorded in the AP system of record is matched against the PO and the goods receipt, known as three-way matching, to ensure accuracy and prevent overpayment. No Medius product page, help center article, release note, or marketing material found across four targeted searches references ERS, self-billing, or any mechanism that bypasses the supplier invoice step and auto-generates a payment document upon GRN confirmation for enrolled suppliers.

This manufacturing buyer needs invoices validated against electronic ASN data as a distinct matching document layer before warehouse receiving is completed, enabling earlier invoice processing without waiting for a physical GRN. Stampli's NetSuite integration is anchored exclusively to completed item receipts as the third leg of the match: the platform pulls open POs and receiving data from NetSuite, matching invoices against what was actually received at the item-receipt level, with data refreshed on a cycle of up to 2 hours or on demand. There is no documented mechanism in Stampli for ingesting ASN records, EDI 856 data, or NetSuite Inbound Shipment records as a surrogate matching document prior to physical receipt confirmation. NetSuite does offer a native 'Bill in Advance of Receipt' feature and an Inbound Shipment Management module that can mark goods as in-transit before physical receiving, but Stampli's integration layer connects to item receipts, not to in-transit inbound shipment status, meaning the early-processing benefit the buyer is seeking cannot be delivered through Stampli's matching engine.

This buyer's manufacturing operation needs to begin processing supplier invoices immediately upon receipt of an electronic ASN (advance shipment notification, EDI 856 or equivalent), using that shipment notification as a surrogate matching document before physical goods receipt is completed at the warehouse dock. Medius's published matching architecture requires a physically recorded goods receipt (GRN) as a prerequisite for 3-way match completion: its own SAP integration documentation explicitly states that 'missing goods receipt deviations cannot be manually approved — Medius follows the best practice approach here and requires a recorded delivery to resolve this type of mismatch.' This positions Medius firmly at Stage 4 of the pre-processing journey (receipt confirmation) only when that confirmation has been formally posted in the connected ERP, not when an ASN has been issued. No Medius documentation, help portal content, or product page references ASN ingestion, despatch-advice (DESADV) matching, or a configurable document hierarchy that would allow ASN data to serve as an interim matching layer in place of a GRN. NetSuite does offer a native 'Bill in Advance of Receipt' feature tied to its Inbound Shipment Management module, which allows billing once a shipment is marked In-Transit — but this is an ERP-native capability that Medius does not appear to surface or orchestrate through its AP automation layer.

This manufacturing buyer requires that when received materials fail quality inspection, the system automatically generates a debit memo or credit expectation against the vendor without manual AP intervention. Stampli's NetSuite integration does document credit memo handling: Stampli's validation algorithm validates PO matching, credit memos, inventory receipts, and invoice closing, and credit memo handling with automatic application during payments is a named capability, where the credit amount is automatically applied when a credit memo is selected along with one or more invoices. A customer confirms this scope directly: "We use Stampli to process all invoices and credit memos into our ERP. It matches things very well and integrates with very little issues." However, what is documented is downstream credit memo processing and application, not upstream automated generation. Stampli operates at the AP pre-processing layer (stages 2 through 5 of the pre-processing journey: PO match, terms verification, receipt confirmation relay, and cost allocation) but defers to NetSuite for the inventory and receiving events that would trigger an RTV document. The rejection signal originates in NetSuite's quality or receiving module, and Stampli has no documented native mechanism to receive that signal and auto-generate a debit memo or credit expectation as a financial document. The buyer would need NetSuite to create the vendor credit memo on the rejection event, after which Stampli can pick it up, apply it at payment time, and keep records in sync — but that is not the automated generation from rejection the requirement describes.

For a manufacturing buyer using NetSuite whose quality team rejects inbound materials and expects an automated debit memo or credit expectation to be created, Medius covers only the downstream half of this workflow. When a matching deviation arises, Medius routes the invoice to its 'Analyze' step, where a designated user investigates and can manually request a credit note from the vendor; as the Rapid Application Delivery workflow guide describes, the user 'might ask for a credit note, update the PO in their ERP to resolve the variance, or approve or reject the deviation.' Once the vendor issues a credit, Medius's Credit memo queue (documented in the MediusGo support portal) allows AP to receive that inbound credit document and link it to the original debit invoice marked as 'waiting for a credit.' What Medius does not do is automatically generate a buyer-side debit memo or credit expectation document at the moment a quality inspection failure or rejection event occurs in NetSuite; that trigger lives entirely in the ERP, and no Medius documentation describes a workflow that listens for a NetSuite rejection event and creates an offsetting financial document without human initiation.