How Medius works

Requirement evaluated: Segregation of duties enforcement: person who enters cannot approve, person who approves cannot process payment

For a 3-person AP team at a multi-location services company, Medius enforces all three legs of segregation of duties through distinct, system-level mechanisms rather than policy-only controls. First, the `AllowInspectAndAttest` system parameter controls whether the user who reviewed and coded an invoice can also approve it: <cite index="33-15">setting this to 'No' means that a person who has reviewed a coding row can never approve the same row.</cite> Second, Medius includes a configurable Four Eyes Principle (4EP) …

Limitations: All three controls (AllowInspectAndAttest, Four Eyes Principle, Pay Approver Role) are configurable settings that must be deliberately activated during implementation; they are not all enabled out-of-the-box, so the buyer's implementation team must confirm each is turned on and that no threshold-based bypass exists (fo …

Requirement evaluated: Dual approval requirement for all capital expenditures regardless of amount

For your AP team processing CapEx invoices across two Sage Intacct entities, Medius enforces dual approval through its dimension-based approval rules engine inside MediusFlow. The trigger is the GL account (or coding dimension) assigned to the invoice, not the invoice amount: when an AP coder tags a line to a capital account range, the approval rules engine routes that invoice through a mandatory sequential approval hierarchy requiring each level to sign off before the next is unlocked. …

Limitations: The documented 4EP configuration example pairs the two-approver requirement with a dollar threshold ($1,000), so confirming that 4EP alone can fire at a $0 floor for CapEx coding rows (with no amount condition at all) …

Requirement evaluated: The solution must support dynamic approval routing that can be configured by NetSuite department, class, or project segment, allowing entertainment production budgets and overhead spend to follow separate approval chains, with role-specific invoice data visibility so that approvers see only the entities and cost centers they are authorized to approve.

For an entertainment business running NetSuite, Medius imports all coding dimensions directly from NetSuite during onboarding, including both standard dimensions (department, class) and custom dimensions such as project. <cite index="28-2,28-3">The structure of coding dimensions, including both standard and custom dimensions, is determined during the data gathering phase of the customer onboarding process, and Medius imports all coding dimensions directly from Oracle NetSuite.</cite> Once those dimensions are live in Medius, administrators configure approval rules against any chosen dimension as the "approval object": <cite index="14-3">approval rules in MediusGo are set up in different role …

Limitations: The standard approval object is configured as a single primary dimension per coding string setup; separating production-budget and overhead chains simultaneously across all three dimensions (department, class, and project) …

Requirement evaluated: The system must support configurable approval-authority limits that tie dollar thresholds and invoice attributes to specific roles or named individuals, so that invoices above a defined amount or of a defined type are blocked from advancing without a qualifying approver on record. Authority limit configurations and any changes to those configurations must themselves be logged in the immutable audit trail, so auditors can reconstruct who held what authority at any point in time.

For a PE-backed company on NetSuite preparing for IPO, Medius delivers a well-documented approval-authority matrix through its MediusFlow module. <cite index="10-1,10-2,10-3,10-4">Approval rights are configured on roles with two enforced dimensions: a maximum approval amount per invoice (the total across all coding rows a user may approve on a single invoice) …

Limitations: The material gap for this IPO-prep buyer is the Admin log's separation from the transaction audit trail and the absence of confirmed immutability: if auditors cannot pull a single, tamper-evident record showing who held what authority limit at what point in time (before/after values, timestamps, actor identity), the co …

Requirement evaluated: Support extraction from non-standard invoice formats common in the tech industry: cloud usage reports, contractor time sheets, conference sponsorship invoices, and developer tool subscription notices.

For a tech-sector buyer whose invoice mix includes SaaS subscriptions, contractor invoices, conference sponsorships, and cloud infrastructure bills, Medius Capture ingests documents arriving by paper, email, EDI, and e-invoice, then applies a proprietary multi-stage AI pipeline, including Siamese CNNs for document classification and SmartFlow, a convolutional neural network trained on 2.4 billion+ invoice field data points drawn from across Medius's customer base, to extract and code data without requiring explicit template configuration per vendor. …

Limitations: Cloud usage reports from providers like AWS, GCP, and Azure present the hardest extraction challenge in this buyer's format mix: they contain dozens to hundreds of line-level SKU rows with usage quantities, rates, and credits in complex tabular layouts that differ structurally from traditional invoice PDFs, and Medius …

Requirement evaluated: Handle invoices embedded in email bodies (not just attachments), HTML-formatted invoices, and invoices with complex multi-column layouts.

For a tech buyer whose vendors send SaaS subscription notices, cloud bills, and contractor invoices across a wide range of formats, Medius Capture addresses this requirement in part. The capture engine uses OCR, AI, and machine learning to extract header and line-item data from PDF, EDI, XML, e-invoices, and paper, and it routes each document through intelligent model selection rather than pre-defined templates, which gives it meaningful resilience against complex or multi-column layouts. On the email ingestion side, Medius accepts invoices via a dedicated company email address: however, the product documentation describes this flow as attachment-based ingestion. …

Limitations: The material gap for this buyer is email-body and inline-HTML invoice extraction: invoices from SaaS vendors (AWS, GCP, Stripe, conference sponsors) that are rendered as formatted HTML in the email body rather than sent as file attachments are not documented as a supported input path in any Medius help center or produc …

Requirement evaluated: Learn from user corrections over time, improving extraction accuracy for recurring vendor invoice formats without requiring explicit template training.

For a tech company processing SaaS, cloud infrastructure, contractor, and staffing invoices from dozens of recurring vendors, Medius addresses this requirement through two interlocking components: Medius Capture and SmartFlow. Medius Capture applies proprietary convolutional neural networks (Siamese CNNs for document classification) and Markov models for line-item extraction, operating at stage 1 (legitimacy and data capture) of the pre-processing journey. The system is explicitly template-free: rather than mapping fields per vendor layout, it interprets context and patterns to identify key information. …

Limitations: The strongest evidence of per-correction learning centers on coding and routing (SmartFlow) rather than the raw character-level extraction layer; buyers should verify during a proof of concept that field-level extraction accuracy (not just coding) …

Requirement evaluated: Extract and validate tax identification numbers, remittance addresses, payment terms, and currency information from invoice headers, flagging mismatches against the vendor master.

For a tech-sector buyer whose invoices arrive from a wide vendor mix (SaaS, cloud, contractors, staffing agencies), Medius validates extracted invoice header fields against the supplier master at the point of capture and again through its Fraud & Risk Detection layer before payment release. At capture, the system checks invoice-level fields against stored vendor records: a documented MediusGo error condition surfaces when 'the invoice's currency and the vendor's currency are different' and 'the invoice's vendor information does not match the supplier registry,' confirming automated currency-vs-master comparison. …

Limitations: Medius's documented examples cite VAT registration and currency as the primary header fields cross-referenced against the supplier master at capture time; buyers should confirm during discovery whether domestic TIN/EIN (as distinct from VAT number) …

Requirement evaluated: The AP automation solution must integrate bi-directionally with NetSuite as the system of record, writing back fully coded bills, vendor records, payment status, and GL entries with full NetSuite field fidelity, including custom segments, classes, departments, and locations, so that no manual re-keying into NetSuite is required at any stage of the invoice lifecycle.

For an entertainment business running NetSuite as system of record, Medius delivers bi-directional integration through its own dedicated cloud connector: a certified 'Built for NetSuite' hybrid SuiteApp (covering AP Automation and Pay) that Medius manages directly, with no third-party middleware involved. On the inbound leg, Medius imports coding dimensions directly from Oracle NetSuite, and its May 2025 product definition document explicitly states that 'the structure of coding dimensions - including both standard and custom dimensions - is determined during the data gathering phase' and that Medius pulls those dimensions from NetSuite's own schema. …

Limitations: While Medius's May 2025 product definition confirms that both standard and custom coding dimensions are imported from NetSuite and that approved invoices post back to NetSuite, the documentation does not provide field-level specificity on how payment status records (e.g., bill payment clearance, open-bill reconciliatio …

Requirement evaluated: The system must support full NetSuite custom segment coding, not only the standard NetSuite dimensions (GL account, location, department, class, project). The buyer explicitly calls out 'several custom dimensions' as part of their standard coding workflow. A vendor whose data model is limited to NetSuite's out-of-the-box fields cannot serve this buyer; the integration layer must read the buyer's NetSuite custom segment configuration and expose those segments as codeable targets in the AP automation UI and AI coding engine.

For a buyer running NetSuite with dozens of coding fields including several custom dimensions, Medius addresses the requirement through a direct schema import from NetSuite at onboarding. The May 2025 Medius AP Automation for Oracle NetSuite product definition states explicitly: 'The structure of coding dimensions, including both standard and custom dimensions, is determined during the data gathering phase of the customer onboarding process. …

Limitations: The product definition document describes the custom dimension import as part of the customer onboarding process, which implies configuration effort at implementation rather than a self-service, real-time sync; if the buyer adds new custom segments to NetSuite post-go-live, it is unclear from available documentation wh …

Requirement evaluated: The NetSuite integration must replicate the full NetSuite data model without truncation, carrying every standard dimension (GL account, location, department, class, project, tax fields) plus all custom segment definitions, line-item splits, and subsidiary structure into the AP automation layer. The buyer's current problem is that their existing tool acts as an ERP glass ceiling, limiting NetSuite usage to a lowest-common-denominator subset of fields. Any replacement must be evaluated on whether it carries the buyer's complete NetSuite configuration, not whether it generically 'integrates with NetSuite.'

For a buyer coding dozens of NetSuite fields per invoice, Medius connects through a dedicated, Built-for-NetSuite certified hybrid SuiteApp called Medius Connect. The managed integration transfers master data from NetSuite into the Medius layer, and the official NetSuite product sheet confirms that Medius pulls 'dimensions directly from Oracle NetSuite' to support coding. Non-PO invoices are coded and approved inside Medius before being posted back to NetSuite, and SmartFlow (Medius's per-supplier CNN-based AI) learns coding patterns from historical actions to automate those decisions over time. …

Limitations: There is no documented evidence that Medius's managed NetSuite connector dynamically reads and exposes the buyer's full custom segment schema at the line level; the integration is described as a 'standardized approach,' and the buyer's dozens of custom fields may require the Medius iPaaS layer plus additional configura …

Requirement evaluated: The AP automation system's audit trail must integrate with Oracle NetSuite at full field fidelity, meaning that every AP event recorded in the AP tool (coding, approval, payment posting) must produce a corresponding, reconcilable record in NetSuite with no dimensional data loss across NetSuite's custom segments, subsidiaries, and transaction fields. A gap between what the AP tool records and what NetSuite receives creates an unauditable seam that external auditors will flag during SOX review; the integration must eliminate that seam entirely.

For a PE-backed NetSuite company preparing for SOX review, Medius connects to NetSuite via a certified, cloud-managed connector that holds 'Built for NetSuite' certification, meaning it follows Oracle SuiteCloud platform development standards and best practices. The integration is positioned as bidirectional: master data flows from NetSuite into Medius so coding dimensions are available during AP processing, and posted invoices, approvals, and payment events flow back to NetSuite's AP ledger. …

Limitations: The 'Built for NetSuite' certification and cloud-managed connector are genuine positive signals, but Medius has not publicly documented field-level coverage of NetSuite custom segments and subsidiary dimensions in its connector; the presence of a simplified FX API path and 'standardized integrations' framing means this …

Requirement evaluated: The AI coding model must learn from this buyer's specific transaction history to improve dimension coding accuracy over time, using the 12,000 monthly invoices as the training corpus. The vendor must explain the actual mechanism (per-customer model, fine-tuning on approval history, rules derived from prior accepted coding, or equivalent) and must not describe a generic pretrained model as if it were customer-specific learning. The buyer's question, 'how does the per-customer model learn from our history,' must be answerable with a concrete mechanism and a measurable lift curve, not a marketing claim.

For a buyer processing 12,000 invoices a month across dozens of NetSuite coding fields, Medius's learning mechanism is delivered through SmartFlow, a CNN-based proprietary model that auto-codes GL account, tax fields, approver values, and coding dimensions for non-PO invoices. The mechanism is explicitly company-specific: according to Medius's invoice automation product page, SmartFlow is 'trained on your historical actions and enriched by 2.4 billion+ invoice field data points across Medius's global customer base,' and a Medius Chief Architect confirmed in a published interview that 'our machine learning technology uses pattern recognition to capture invoices, code them correctly, and route …

Limitations: Medius does not publish a measurable lift curve showing accuracy improvement as a function of invoice volume past the cold-start '95% after two invoices' benchmark, so the buyer cannot verify the concrete progression their 12,000 monthly invoices would drive. …

Requirement evaluated: For any field the AI cannot code autonomously, the system must apply a defined fallback behavior rather than silently leaving the field blank or passing an incomplete record to NetSuite. Acceptable fallback behaviors include: routing the specific uncoded field to the appropriate budget owner or cost center manager for manual entry, applying a configurable default value with a review flag, or holding the invoice in a structured exception queue with the uncoded fields clearly identified. The buyer specifically asks 'what happens to the fields the tool cannot code,' meaning silent omission or generic rejection is not an acceptable answer.

For a buyer coding dozens of NetSuite fields per invoice, including custom dimensions, Medius provides multiple layered fallback mechanisms so that no invoice silently leaves coding incomplete before posting. At the capture and verification stage, invoices that fall below a configured data-confidence threshold are moved to a dedicated work queue for manual correction rather than passed forward with blank fields: as Medius's own invoice data capture documentation states, 'invoices where data capture accuracy falls outside the predefined confidence levels will be moved to a separate work queue, where they can be manually verified and corrected by an AP department member.' Within the coding wor …

Limitations: The documentation does not describe a native mechanism for field-level routing of an uncoded dimension directly to a specific budget owner or cost center manager (e.g., 'this cost center field is blank; route only that field to the cost center manager for entry'); the fallback routes the whole invoice to a queue or a d …

Requirement evaluated: For each of the 12,000 invoices processed monthly in Oracle NetSuite, the AP automation system must extract and present structured line-item data from every invoice line, not just header-level fields such as vendor, date, and amount. This is the prerequisite for any meaningful dimension-level coding: if the tool can only parse header data, all downstream coding attempts are limited to a single row per invoice regardless of how many line splits the organization requires.

For a buyer processing 12,000 invoices monthly in NetSuite with dozens of coding fields per invoice, Medius Capture uses a proprietary multi-stage AI pipeline, including Siamese CNNs for document classification and proprietary Markov models specifically for line-item extraction, to produce structured, per-line data from every invoice before any coding occurs. The Medius help center documents that the capture step identifies and presents each invoice line visually, with recognized lines highlighted for review or correction, and that the coding step then operates on a full multi-row Coding Table where each row carries multiple Accounting Dimensions. …

Limitations: Medius's published precision metric of 95%+ applies after two invoices per supplier for non-PO invoices; buyers with a very large number of custom dimensions or sparse per-supplier invoice history may see lower auto-coding rates on those specific dimensions until the model accumulates sufficient correction data. …

Requirement evaluated: The system must autonomously code every NetSuite dimension field at the line level for each of the 12,000 monthly invoices, specifically: GL account, location, department, class, project, all custom segment dimensions, and tax fields. Auto-coding must apply per line split, not once at the header, because the buyer explicitly describes line-level splits as standard practice. The vendor must be able to demonstrate exactly how many of these named fields its AI codes autonomously versus how many remain for human entry, and must not conflate header-level coverage with full-invoice coverage.

For a buyer processing 12,000 invoices a month across dozens of NetSuite dimensions with line-level splits, Medius operates at step 1 (legitimacy and coding) of the pre-processing journey. The integration is built on a documented mechanism where the code plan is read directly from NetSuite: as the May 2025 Medius AP Automation for Oracle NetSuite datasheet states, 'The structure of coding dimensions — including both standard and custom dimensions — is determined during the data gathering phase of the customer onboarding process,' and 'Medius imports all coding dimensions directly from Oracle NetSuite.' This means the field set Medius works with originates in NetSuite's own schema, covering b …

Limitations: The documented partial gap is twofold: PO invoices with quantity discrepancies explicitly receive no automatic coding and require manual resolution per the NetSuite datasheet; and SmartFlow's confidence on multi-line invoices with novel or infrequent coding patterns grows over time, so autonomous coding rates on comple …

Requirement evaluated: Spend analytics: top vendors, spend by GL category, month-over-month trending

For a $120M multi-location services company running two Sage Intacct entities, Medius addresses this requirement through Medius Analytics, a dedicated reporting module with out-of-the-box dashboards that are automatically available upon deployment. The module delivers a real-time spend analysis view covering cashflow, costs, and forecasts through pre-defined reports, dashboards, and KPIs, with drill-down capability to the individual supplier level for vendor performance monitoring. …

Limitations: Documentation confirms the named dashboards and the supplier- and dimension-level filtering mechanism, but the exact out-of-the-box layout of a 'top vendors' ranked list or an explicit MoM trend chart is not shown in public help articles; buyers should request a live demo of the Cashflow and Overview dashboards to conf …

Requirement evaluated: Cash flow forecasting based on approved and pending payables with due date distribution

For a $120M multi-location services company currently flying blind on payables timing, Medius delivers a dedicated Cashflow Dashboard within its Medius Analytics module, listed as a named pre-built dashboard in the Medius help center documentation alongside the Overview, Capture Insights, and Straight Through Processing dashboards. The mechanism works because Medius sits in the pre-processing layer: every invoice, whether still in an approval queue or fully approved and awaiting payment, lives in the Medius pipeline with its due date, payment terms, and workflow status tracked in real time. …

Limitations: The Medius Analytics layer, which houses the Cashflow Dashboard, refreshes on a Medius-managed schedule rather than continuously, so the view is a periodically updated snapshot rather than a second-by-second live feed; the operational gadget dashboards do update in real time but are invoice-status views rather than for …

Requirement evaluated: Approval bottleneck analysis: which approvers are slowest, which invoice types take longest

For your 3-person AP team processing 1,800 invoices monthly across two Sage Intacct entities, Medius addresses this requirement through its named Medius Analytics module, which is included in the vendor's modular suite. Medius's own documentation states that 'AP leaders can track bottlenecks by entity, approver, supplier, or category and take action before suppliers follow up,' directly matching your need to identify which approvers are slowest and which invoice types take longest. …

Limitations: A third-party review (research.com, 2026) notes 'limited customization options for reports, restricting tailored outputs,' which means buyers who need highly bespoke drill-down combinations beyond the pre-built dashboard views may hit constraints in report configuration. …

Requirement evaluated: The solution must provide spend reporting and accrual visibility segmented by NetSuite class, department, and project or production, enabling finance teams in an entertainment business to compare actual AP spend against production budgets and identify cost overruns before payment is released.

For this entertainment company's production budget visibility requirement, Medius begins by syncing all coding dimensions directly from NetSuite during onboarding: the official NetSuite integration specification confirms that 'the structure of coding dimensions—including both standard and custom dimensions—is determined during the data gathering phase' and that 'Medius imports all coding dimensions directly from Oracle NetSuite,' which means class, department, and project fields are available for invoice coding throughout the AP workflow. …

Limitations: The critical gap for an entertainment finance team is that Medius's Analytics module does not appear to natively ingest NetSuite production budget values and surface a budget-vs-actual report segmented simultaneously by class, department, and project: the analytics dashboards are documented around AP process KPIs, not …

Requirement evaluated: Virtual card program with rebate revenue; we want to shift 30%+ of spend to virtual card

For a US-based multi-location services company aiming to convert 30%+ of AP spend to virtual card, Medius delivers this through Medius Payments (their own payment module, priced separately from the core AP automation product). Once invoices are approved in the AP workflow, Medius Payments routes each payment to the optimal method: virtual card, ACH, wire, or check. For virtual card transactions, Medius issues a unique, single-use card number tied to a specific invoice and dollar amount; after the supplier processes it, the card self-destructs, closing the payment loop back to the ERP. …

Limitations: Virtual cards through Medius Payments are available for US-based businesses only, which is not a blocker for this buyer but would be relevant if international supplier payments were added later. …

Requirement evaluated: Virtual card program with rebate revenue; we want to shift 30%+ of spend to virtual card

For a $120M services company currently running manual check and ACH runs through Sage Intacct, Medius Payments delivers a fully integrated virtual card program as part of its payment execution layer. Once invoices clear the AP automation workflow and are approved, Medius Payments generates a unique, single-use card number tied to the specific invoice amount and supplier, automatically dispatches remittance advice, and then imports card reconciliation reporting back into the connected ERP, closing the loop without manual uploads. …

Limitations: Virtual cards are available for US-based operations only, which is consistent with this buyer's profile, but any non-US supplier payments will not generate vCard rebates. …

Requirement evaluated: International wire payments to 8 overseas vendors with multi-currency support

Your AP team currently generates international wire instructions manually outside Sage Intacct for 8 overseas vendors. With Medius Payments (the vendor's payment execution module, priced separately from core AP automation), once an invoice completes the Medius approval workflow, a wire payment is formatted within Medius using the vendor's stored SWIFT/BIC code or IBAN, then transmitted via secure FTP directly to your financial institution's wire desk for settlement — no manual Sage Intacct export or separate bank login required. …

Limitations: For US-based companies, the international wire execution model routes formatted wire instructions through your existing financial institution's wire desk via secure FTP rather than through Medius's own direct payment rails, so settlement speed and any per-wire fees remain subject to your bank's international wire polic …

Requirement evaluated: International wire payments to 8 overseas vendors with multi-currency support

For a $120M services company paying 8 overseas vendors, Medius Payments handles international wire execution natively within the AP workflow, eliminating the need for a separate payment portal or manual file export. The module supports SWIFT and IBAN wire transfers alongside SEPA, BACS, CHAPS, BankGiro, ACH, checks, and virtual cards across the US, Europe, and the rest of the world in a single consolidated process per supplier. A June 2025 capability called Straight Through Payments allows payment batches to be built and executed directly from Medius with no ERP file uploads or middleware required, with payments routed through customers' existing bank accounts. …

Limitations: Medius's documentation confirms support for US, Europe, and 'rest of world' but does not publicly enumerate specific countries or currencies covered by the local-bank routing network; for vendors in less common markets, the buyer should confirm country and currency coverage during the sales process. …

Requirement evaluated: The solution must maintain a complete, timestamped audit trail for every invoice action, including capture, coding change, approval, rejection, and payment, stored in a way that can be exported and cross-referenced against the corresponding NetSuite transaction record, supporting the internal audit and compliance requirements common in entertainment businesses with investor or studio reporting obligations.

For an entertainment business running NetSuite with investor and studio reporting obligations, Medius maintains a continuous, timestamped audit record across the full invoice lifecycle. Starting at capture, every invoice is automatically archived and its entire processing history is logged: AI extraction decisions, coding changes, routing steps, approvals, rejections, exceptions flagged by fraud detection, and payment execution are all captured as system events. As Medius documents: 'auditors can quickly access timestamped records of every action — from submission to approval to payment' (Medius e-invoicing blog, May 2025). …

Limitations: Publicly available documentation describes the export path primarily through invoice search gadget exports to Excel and hyperlinked report fields, rather than a documented single-click structured export that pairs every raw Medius event record side-by-side with the corresponding NetSuite internal transaction ID in one …

Requirement evaluated: The system must enforce role-based access controls (RBAC) at a granular level, limiting each user's visibility and action permissions to only the invoices, vendors, GL accounts, cost centers, and approval queues relevant to their role. Permission assignments and any changes to them must be logged with the identity of the administrator who made the change and the timestamp, so that access creep and unauthorized permission escalation are detectable during a SOX audit.

For a PE-backed company on NetSuite preparing for SOX, Medius (via MediusGo) provides a structured role-based permission model administered through its Administration Tool. <cite index="15-4,15-5,15-6">Invoices and permissions are managed through users and roles, where a user represents a personal login with all activity linked to that login, and roles control which functions and permissions each user has.</cite> <cite index="6-10,6-11,6-12,6-13,6-14,6-15">Role permissions are set per company entity and cover approval rights (which amounts and coding values the role may approve), report and search access rights, special approval rules, coding rights, and administration tool rights.</cite> <c …

Limitations: The material gap for this SOX buyer is the second half of the requirement: no documented mechanism was found showing that permission assignments and changes to them are logged with the identity of the administrator who made the change and a timestamp, which is the specific evidence SOX auditors need to detect access cr …

Requirement evaluated: The system must maintain an immutable, timestamped, per-action audit log covering every discrete event in the AP lifecycle: invoice receipt, data extraction, coding, each approval action, exception handling, payment initiation, and ERP posting to NetSuite. No event may be deleted, overwritten, or backdated after it is written; the log must be append-only and cryptographically or architecturally protected against alteration by any user including administrators. This directly addresses the buyer's stated requirement that no action in the AP lifecycle is unrecorded or editable after the fact.

For a PE-backed company on NetSuite preparing for SOX readiness, Medius delivers a meaningful lifecycle-spanning audit trail that covers the pre-processing journey from invoice receipt through payment execution. On the supporting side: <cite index='21-7,21-8'>Medius states that 'all risk is automatically flagged, mitigated and logged across the AP lifecycle' and that 'AI-powered extraction removes the need for manual data entry, while every invoice is automatically archived, ensuring accuracy, traceability, and audit confidence at any time.'</cite> A Medius e-invoicing blog confirms that <cite index='29-7,29-8'>e-invoicing combined with Medius AP Automation 'provides a clear digital audit tr …

Limitations: Medius documents a comprehensive, timestamped, lifecycle-spanning audit trail, but it makes no public claim that the log is architecturally or cryptographically protected against post-write alteration by administrators: the critical distinction between 'comprehensive logging' and 'immutable logging' that SOX auditors a …

Requirement evaluated: The system must enforce configurable segregation of duties (SoD) controls at the role level, ensuring that no single user can perform conflicting actions across the AP lifecycle; for example, the same user who enters or approves an invoice must be structurally prevented from also authorizing or executing the corresponding payment. SoD rules must be enforced by the system architecture, not by policy alone, so that violations are impossible rather than merely prohibited, supporting the buyer's SOX readiness requirements ahead of IPO.

For a PE-backed NetSuite company preparing for IPO-level SOX scrutiny, Medius provides a layered but configuration-dependent SoD architecture rather than an architectural guarantee that conflicting roles are impossible to assign. The core mechanism operates at three levels. First, role-based approval rights (administered under Organization-Roles) control which users can approve which GL coding dimensions and up to what dollar amounts; <cite index="45-3,45-4">approval rights are governed by Approval rules set up in the administration tool, and the system prevents a user from approving rows where they lack permission (the approval box is grayed out).</cite> Second, the AllowInspectAndAttest sy …

Limitations: The critical gap for this buyer's SOX requirement is that SoD enforcement depends on correct administrative configuration rather than architectural immutability: an admin who assigns a user to both an invoice-approval role and the Pay Approver Role is not structurally blocked from doing so, and the AllowInspectAndAttes …

Requirement evaluated: Perform automated matching of purchase order, goods receipt (GRN), and invoice. Support configurable tolerance thresholds by commodity type, vendor, plant, or dollar amount.

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

Limitations: The documented tolerance architecture segments rules by supplier and by company, but not by commodity category or plant/receiving location. This is a material gap for the buyer's manufacturing scenario, where the same supplier may ship raw steel (requiring a +/-2% tolerance), precision-machined components (requiring ex …

Requirement evaluated: Support differentiated tolerance rules by commodity category: raw steel at +/- 2% quantity tolerance for weight-based materials, precision-machined components at exact match, MRO supplies at +/- 5%, and hazardous chemicals at exact match for regulatory tracking.

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. …

Limitations: Medius's tolerance hierarchy is limited to company level and supplier level. There is no documented commodity-category, item-classification, or procurement-group level at which the buyer could independently assign +/-2% to raw steel, exact match to precision components and hazardous chemicals, and +/-5% to MRO. …

Requirement evaluated: Automatically approve invoices that pass all matching criteria within tolerance, achieving touchless processing for routine procurement invoices.

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. …

Limitations: Touchless auto-approval rates are benchmarked across Medius's full customer base; a manufacturer with complex multi-line, multi-plant, or non-standard format invoices may initially land below the 96.3% headline rate until the AI model has accumulated sufficient invoice history for that supplier format. …

Requirement evaluated: Handle multi-line PO matching where individual lines are allocated to different production jobs, work orders, cost centers, or projects. Match invoice lines to the correct PO line and allocation, even when the vendor invoice groups items differently than the PO.

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. …

Limitations: When a vendor invoice groups items differently from the PO line structure (e.g., one invoice line covers three PO lines allocated to three separate production jobs), Medius flags the unresolvable lines for manual connection rather than auto-splitting the invoice line back across the disaggregated PO allocations. …

Requirement evaluated: Learning capability: accuracy should improve over time on our specific vendor invoice formats

For a 1,800-invoice-per-month services company starting from zero automation, Medius addresses this requirement through two complementary mechanisms in its invoice capture stage (pre-processing stage 1: legitimacy and initial data extraction). First, Medius Capture uses a proprietary multi-stage AI pipeline combining Siamese CNNs for document classification and Markov models for line-item extraction, trained on a global corpus of 2.4 billion+ invoice field data points including 393 million real-world human corrections across its customer base. Second, and directly relevant to per-vendor format improvement, SmartFlow (a proprietary CNN) …

Limitations: The precise boundary between global cross-customer model retraining and this buyer's tenant-specific model is not fully disclosed in public documentation; accuracy improvement on genuinely novel or low-volume vendor formats depends on correction volume from this buyer's own invoice corpus, and very infrequent suppliers …

Requirement evaluated: Learning capability: accuracy should improve over time on our specific vendor invoice formats

For a multi-location services company currently keying invoices manually, Medius Capture directly addresses stage 1 of the pre-processing journey (invoice legitimacy and data extraction) through a proprietary multi-stage AI pipeline. The capture engine uses Siamese CNNs for document classification, tree-based ensembles for confidence scoring, and Markov models for line-item extraction, trained since 2016 on 2.4 billion+ invoice field data points, including over 393 million real-world human corrections on edge cases such as tax codes and cost centers. …

Limitations: The 95%+ precision benchmark is reached after two invoices per supplier, but your mix includes niche subcontractors and one-off service providers that may appear infrequently; those low-volume suppliers will take longer to accumulate enough data points to achieve high touchless rates, and the AP team will need to monit …

Requirement evaluated: Learning capability: accuracy should improve over time on our specific vendor invoice formats

For a 3-person AP team manually keying 1,800 invoices per month with no prior automation, Medius Capture addresses Stage 1 of the pre-processing journey (invoice capture and data extraction) using a multi-stage proprietary AI pipeline: Siamese CNNs for document classification, Markov models for line-item extraction, and a CNN-based coding engine called SmartFlow. …

Limitations: The 95% precision benchmark is for SmartFlow's GL coding suggestions on non-PO invoices; Medius does not publish a comparable per-supplier format accuracy lift curve or a time-to-stabilization figure for extraction fields specifically (as opposed to coding), so the buyer cannot pre-validate how quickly a new, complex s …

Requirement evaluated: Automatic extraction of: vendor name, invoice number, date, PO number, line items, amounts, tax, and payment terms

For a 3-person AP team at a $120M services company currently keying 1,800 invoices per month by hand into Sage Intacct, Medius addresses Stage 1 of the pre-processing journey (legitimacy and data capture) through a dedicated module called Medius Capture. The module combines OCR, AI, and ML to extract structured data from paper, PDF, XML, EDI, and email-based invoices without requiring manual templates for each new vendor layout. …

Limitations: No public help-center documentation enumerates every extractable field by name with a confirmed mapping to Sage Intacct field IDs, so the buyer should validate during a structured proof-of-concept that PO number and payment terms pass through to Intacct at full fidelity, not just as captured text. …

Requirement evaluated: The solution must support multi-entity AP processing reflecting the subsidiary and production-company structures typical of an entertainment business, with per-entity GL charts of accounts, NetSuite subsidiary selection at the bill level, and intercompany transaction visibility, so that invoices routed to the wrong entity are flagged before coding is finalized.

For an entertainment business running multiple subsidiaries and production companies in NetSuite, Medius organizes its AP platform around a 'company' concept that maps directly to each legal entity. Each company gets its own coding string, and the code plan — the list of GL accounts and dimensions available for invoice coding — is read directly from NetSuite and is considered owned by the ERP, so the accounts available to a coder on any given invoice reflect the accounts valid for that NetSuite subsidiary. …

Limitations: Medius does not document a proactive, named 'entity mismatch' flag that fires at invoice intake or company-assignment stage before a coder touches the bill; entity errors surface reactively when coding fails restriction-rule validation or when the supplier is not found under the assigned company, rather than as a dedic …

Requirement evaluated: The system must support role-based cross-unit visibility grants, so that designated users (central accounting staff, controllers, or payment administrators) can view and act on invoices across all 9 productions simultaneously, while production-level AP users remain restricted to their own unit. This is the mechanism that makes centralized payment runs possible without granting every AP clerk access to every production's invoice queue.

For a media company running 9 productions as profit centers inside one Sage Intacct legal entity, Medius provides a layered RBAC architecture that enforces intra-entity data isolation without creating separate books. The mechanism operates across three documented layers. First, <cite index="34-1,34-5,34-6">the role form's 'Coding rights' tab restricts which dimension values a user can access when coding invoices; an administrator enables dimension-level filtering in System Configuration, then assigns each role only the profit center codes belonging to its production, so a production-A AP clerk cannot select or see production-B cost centers.</cite> Second, <cite index="27-1,27-2">the role for …

Limitations: The documentation confirms dimension-scoped coding rights and search access, but does not explicitly state that the live work queue inbox filters invoice list visibility by dimension value independent of workflow addressee assignment: if invoices are routed to a shared queue rather than a production-specific queue, an …

Requirement evaluated: The system must enforce invoice visibility isolation across all 9 active productions within a single Sage Intacct legal entity using dimension-based or permission-based access controls, not separate entity or subsidiary configurations. Each production's AP team must be restricted to viewing, editing, and acting only on invoices coded to their own production's profit center, replicating Intacct's profit center dimension as the isolation boundary without fragmenting the chart of accounts or the book of record.

For a media production company running 9 active productions as profit centers inside one Sage Intacct legal entity, Medius offers role-based and dimension-based controls that partially address the isolation requirement, but the architecture has a material ceiling. On the permission side, Medius roles carry a 'Report and Search access rights' tab that controls which invoices a role can search and view in the system; these rights are scoped per company in Medius's data model. (Source: 'Roles, report and search access rights' on MediusGo Customer Portal — see sourceUrl.) …

Limitations: Medius's invoice visibility controls are scoped to the company object, not to a sub-company dimension value; a production AP user who shares the same Medius 'company' as other productions will be able to see invoices for those other productions in the inbox and search, unless each production is configured as a separate …

Requirement evaluated: The solution must handle intercompany invoices natively within the NetSuite OneWorld context: when an invoice is raised between two of the buyer's 14 subsidiaries, the AP tool must recognize the intercompany relationship, route the transaction appropriately, and write back to NetSuite in a way that preserves NetSuite's intercompany elimination and consolidation integrity rather than treating the transaction as a third-party payable. The vendor must document exactly how intercompany invoice records are created or matched in NetSuite and whether the write-back respects NetSuite's intercompany journal and elimination framework.

For a shared-services AP team processing invoices across 14 NetSuite OneWorld subsidiaries, the critical question is whether Medius's write-back to NetSuite creates a properly flagged intercompany vendor bill using NetSuite's Automated Intercompany Management framework, or simply posts a standard vendor bill that is invisible to NetSuite's period-close elimination process. NetSuite OneWorld requires that intercompany vendor bills be created against intercompany-designated A/P accounts (not standard A/P accounts) and that the counterparty vendor record carry the 'Represents Subsidiary' field so the transaction is automatically marked for elimination at period close. …

Limitations: The absence of any Medius documentation on intercompany-specific write-back mechanics is the material ceiling: if Medius posts standard vendor bills without intercompany A/P account designation, those transactions will not be picked up by NetSuite's period-close elimination checklist, creating consolidation integrity b …

Requirement evaluated: Vendor self-service portal: new vendor registration, W-9/W-8 submission, banking detail entry, invoice submission, payment status inquiry

For a $120M services company currently managing vendor onboarding entirely via email and manual data entry into Sage Intacct, Medius offers a dedicated, supplier-only self-service portal that covers all five sub-requirements in the buyer's ask. On the registration and onboarding side, <cite index="4-1,4-13">a dedicated self-serve portal gives suppliers the flexibility to respond to onboarding forms from all of their customers in one place; it is vendor management software that puts the onus on the supplier to onboard and maintain their details in a secure, self-service online portal.</cite> The buyer's AP team creates and issues onboarding forms in Medius Supplier Onboarding; <cite index="24 …

Limitations: Medius's onboarding questionnaires are configurable for document upload including tax forms, but no Medius documentation explicitly confirms a native W-9/W-8 collection workflow with IRS TIN matching or automated validation; buyers with high volumes of subcontractors who need structured, validated tax-form collection s …

Requirement evaluated: 1099 preparation: automated classification, threshold tracking, and electronic filing

For your $120M services company processing 1,800 invoices per month through Medius and Sage Intacct, 1099 preparation is not a capability Medius delivers. Medius's documented product scope covers invoice capture, AI coding, approval workflow, and payment execution; no feature set for vendor tax classification (1099-NEC vs. 1099-MISC), cumulative payment threshold tracking, W-9 or TIN collection, or IRS e-filing appears anywhere in Medius's primary or supporting documentation, its help center (success.medius.com), or its product marketing pages. …

Limitations: Medius provides no mechanism for automated vendor tax classification, rolling threshold tracking, or IRS e-filing; the buyer must manage the entire 1099 lifecycle inside Sage Intacct's native module and its TaxBandits e-file integration as a parallel workflow, separate from whatever Medius does in the AP pre-processing …

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

The buyer's scenario is a distribution company where warehouse and operations staff are not entering goods receipts in NetSuite, leaving three-way match nonfunctional. Medius does operate at the invoice-processing stage and surfaces missing goods receipts as a deviation type: a documented product feature called 'Show goods receipt deviation first' routes invoices with missing GRs to the responsible user before price deviations are handled, prioritizing GR resolution in the AP workflow (Medius Customer Success Top Tips, success.medius.com). …

Limitations: No published Medius case study explicitly documents a before/after measurement of goods receipt capture rates in an organization where employees were not recording receipts, nor does Medius publish evidence of a proactive outbound notification workflow that prompts warehouse or receiving employees to confirm delivery w …

Requirement evaluated: The system must provide a self-service vendor portal where suppliers can submit invoices directly, check payment status, and respond to queries from AP, reducing inbound email volume and giving AP a single structured intake channel. For the buyer's three-entity structure, the portal must allow vendors to indicate or confirm which legal entity the invoice is addressed to at submission time, so that entity-level routing can begin without manual AP triage.

For this buyer's three-entity D365 Finance environment, Medius provides a dedicated Supplier Portal described as a 'single point-of-entry for suppliers to view, register, record and update their details in a cloud-based location.' During supplier registration, the portal requires suppliers to configure their own legal entities before they can begin invoicing customers, establishing the supplier-side identity. …

Limitations: The core gap for this buyer is the absence of documented evidence that the Medius Supplier Portal surfaces a buyer-entity selection field at invoice submission time: the intake mechanism Medius documents is per-company email routing (an AP-managed step), meaning AP staff must still triage or pre-sort submissions by ent …

Requirement evaluated: Approved POs push to NetSuite automatically; payment status syncs back

For a $250M technology company currently creating POs manually in NetSuite, Medius replaces that manual workflow through its 'Built for NetSuite' certified SuiteApp, which extends NetSuite's existing procure-to-pay functionality rather than replacing it. Approved POs created in Medius Procurement flow directly into NetSuite via a cloud-managed connector that Medius maintains; no custom coding or file uploads are required. The integration is bi-directional: vendor master data, PO lines, and goods receipt data sync from NetSuite into Medius, and once an invoice clears the Medius approval and matching workflow, the posting (preliminary, cancel, and final) writes back to NetSuite automatically. …

Limitations: The depth of PO-line data flowing into the connector depends on the NetSuite integration package version in use; buyers should verify that the connector imports PO lines before goods receipts are confirmed, which is a configuration requirement Medius documents for its goods-receipt deviation routing feature. …

Requirement evaluated: Matched invoices push to NetSuite AP for payment processing (or integrate with our AP automation tool)

For a $250M tech company running NetSuite as its ERP of record, Medius delivers this requirement through a dedicated, cloud-managed NetSuite connector that is part of Medius's own product suite. Medius is a fully approved NetSuite vendor and holds 'Built for NetSuite' certification for its AP Automation and Pay SuiteApps, meaning the integration is built on Oracle's SuiteCloud platform and maintained by Medius without custom development or third-party middleware. …

Limitations: Medius operates as an external platform that syncs into NetSuite rather than processing entirely inside the NetSuite UI, so finance staff will work across two interfaces during AP processing; this is by design for the deeper automation Medius provides, but represents a change management consideration for a team current …

Requirement evaluated: SSO via Okta (our identity provider)

For a technology company using Okta as its identity provider, Medius supports federated SSO via SAML 2.0. Medius has a published integration tile in the Okta Integration Network (OIN) under 'Medius Corporation,' listed with SAML as a supported authentication type alongside OIDC, enabling authentication and provisioning capabilities directly from the Okta admin console (okta.com/integrations/medius-corporation/). …

Limitations: The OIN listing carries the legacy 'Medius Corporation' entity name and a supply-chain-oriented description; buyers should confirm with Medius sales or implementation that the current Medius AP/Spend Management cloud product maps to this OIN tile and that SCIM-based automated provisioning/deprovisioning (beyond SSO alo …

Requirement evaluated: Sync scope: chart of accounts, departments, classes, locations, projects, vendor master, items, and custom segments

For a $250M technology company running NetSuite as its ERP of record, Medius delivers its NetSuite data sync through two integrated mechanisms: the Medius Connect fully managed ERP connector and the certified 'Built for NetSuite' SuiteApp (Medius Procurement for NetSuite), which is built directly on the Oracle NetSuite SuiteCloud Platform. The Medius Connect page explicitly states that 'master data is accurately transferred from the ERP application to Medius AP Automation' for NetSuite, and the Built for NetSuite press release confirms the SuiteApp 'leverages NetSuite's integrated business system to manage supplier master data and financial account details,' covering vendor master and chart …

Limitations: Custom segments, which this buyer may use for project tagging or additional cost dimensions in NetSuite, are not explicitly documented in any Medius-published source found; the buyer should require Medius to confirm custom segment read scope in writing before contracting. …

Requirement evaluated: Track partial shipments against PO lines, match invoices against received quantities, and maintain open PO balances for backordered items. Prevent overpayment by blocking payment for quantities not yet received.

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 …

Limitations: The quality of partial receipt tracking depends directly on the timeliness of item receipt sync from NetSuite into Medius; the Medius documentation itself notes that invoices may arrive in the system before deliveries are transferred from the purchasing system, meaning a lag in NetSuite GRN posting creates a window whe …

Requirement evaluated: Handle split deliveries where a single PO line is received across multiple plants, warehouses, or dock locations, matching invoices against the aggregate received quantity.

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. …

Limitations: No Medius documentation confirms that its matching engine aggregates goods receipt quantities across multiple NetSuite location/warehouse codes per PO line before invoice validation; if location is treated as a matching dimension rather than being collapsed first, every split-site delivery against a single PO line woul …

Requirement evaluated: Support evaluated receipt settlement (ERS) where payment is generated automatically upon goods receipt confirmation without requiring a vendor invoice, for suppliers enrolled in the program.

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. <cite index="39-5">Invoice matching in Medius is used when a vendor invoice is preceded by a purchase order from the buying organization.</cite> The system then matches that inbound invoice against the PO and goods receipt for 3-way validation. …

Limitations: Medius's matching engine is invoice-led by design: it waits for an inbound supplier document before creating a payable record, which is the structural anti-pattern for ERS. …

Requirement evaluated: Handle advance shipment notification (ASN) matching where invoices are validated against electronic ASN data before physical receiving is completed, enabling earlier processing of invoices.

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

Limitations: Medius's documented architecture hard-stops invoice clearance until a physical goods receipt is recorded in the ERP; there is no ASN-as-matching-document capability, no configurable pre-receipt invoice staging queue, and no EDI 856 or DESADV ingestion documented anywhere in its product suite. …

Requirement evaluated: The solution must support project-level or production-level cost coding at the invoice line level, allowing each line to be allocated to a specific NetSuite project, job, or custom segment that represents a production, so that below-the-line and above-the-line costs in entertainment productions can be tracked and reported separately without manual GL journal entries.

For an entertainment business running NetSuite, Medius handles production-level cost coding at the invoice line level through its dimension coding framework. During onboarding, Medius pulls the full coding schema directly from NetSuite: as the official May 2025 product definition states, 'the structure of coding dimensions—including both standard and custom dimensions—is determined during the data gathering phase... Medius imports all coding dimensions directly from Oracle NetSuite.' This means any NetSuite dimension representing a production—whether a standard Class/Department or a custom segment configured to track above-the-line vs. …

Limitations: The May 2025 NetSuite product definition PDF excerpt is slightly truncated at the passage describing custom dimension activation, so it is not explicitly confirmed whether NetSuite SuiteGL-based Custom Segments (as distinct from standard custom fields) …

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

For a multi-location construction company on NetSuite where subcontractor receipt confirmation comes from field personnel rather than a warehouse dock, Medius supports genuine 3-way matching (PO, goods delivery receipt, and invoice) as a named, documented product capability. <cite index="23-1,23-5">The platform can automatically match invoice line details against purchase orders, goods receipts, and/or contracts to resolve discrepancies in invoices, POs, and receivables.</cite> The RAD (Rapid Application Delivery) …

Limitations: Medius's 3-way match is designed around goods receipts that originate as records in NetSuite before or during invoice processing; for subcontractor invoices where no ERP goods receipt exists, the missing-GR exception route can direct the invoice to a responsible user, but this is reactive exception handling rather than …

Requirement evaluated: For every PO-based order where goods are expected, the system must proactively prompt the original requester to confirm receipt when the expected delivery date arrives or when a vendor shipment signal is received, eliminating the manual step that currently causes receiving records to go unrecorded in NetSuite. The prompt must be actionable: the requester must be able to confirm full receipt, partial receipt with quantity, or report non-receipt directly from the notification without logging into NetSuite.

For this distribution company where nobody returns to NetSuite to confirm receipt, Medius's closest mechanism is its invoice-triggered missing-GR deviation routing, not a delivery-date-triggered outbound prompt. When an invoice arrives and no goods receipt exists in the connected ERP, Medius can be configured with a 'Show goods receipt deviation first' toggle: <cite index="14-1,14-3,14-6,14-7">the system prioritizes missing GRs over price deviations and routes invoices with a missing GR to the responsible user first; only after the GR is completed are any remaining price deviations routed for handling.</cite> The standard PO invoice workflow reinforces this: <cite index="29-7">the system att …

Limitations: Medius's missing-GR routing fires only when an invoice arrives, which means the receiving gap stays open for every order where the vendor delays invoicing or where the invoice never triggers the exception path; the buyer's specific need for a proactive, delivery-date-triggered prompt to the original requester that can …

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

This distribution company currently has no receiving records in NetSuite, which collapses three-way match to two-way; Medius directly addresses this by treating the goods receipt as a first-class matching object. Medius imports PO lines and goods receipt records from NetSuite into its own matching engine, where AI-powered logic compares invoice lines against both the PO and the GDR at the line level, flagging quantity and price deviations automatically. …

Limitations: The buyer specifically requires match results and exception-handling lineage to be written back to NetSuite at the record level so auditors can trace the full match history inside the ERP; Medius stores the detailed match workflow log (deviations flagged, approver actions, GR confirmation timestamps) …