Stampli vs Vic.ai vs Medius vs BILL vs Ramp for AP Automation

For a buyer running 12,000 invoices per month in NetSuite with dozens of coding dimensions, Vic.ai's Autopilot engine operates at pre-processing stage 1 (legitimacy and coding) and addresses the exact failure mode described: header-only coding that stops at vendor, date, amount, and a single GL account. The mechanism is a per-customer deep learning model that ingests historical transaction data and invoice images during an initial training period of approximately two weeks, then generates predictions at the line-item level across every dimension the buyer's ERP exposes. As soon as an invoice is ingested, the AI predicts the vendor, invoice number, invoice date, due date, payment terms, GL accounts, and any dimension such as Customer, Location, Department, and so on, doing this for every single line item. The scope of dimensions is not limited to NetSuite's native segments: line-item coding includes posting to dimensions such as class, job, or location, splitting items across many GL accounts, and recognition and coding of VAT and other taxes. The per-customer learning model is trained directly on the buyer's own historical coding decisions: the AI is intelligent enough to predict all the values necessary to properly code an invoice from header-level fields to line-item fields not explicitly on the invoice, and because of historical data training, the AI has seen previous examples of a specific vendor invoice and knows the proper GL account and dimensions to code to. The Q1 2026 product release confirms active investment in custom field coverage: the platform now auto-applies PO dimensions to matched invoice lines, preserves line-level dimension and tax code variations in document-level PO matching, and supports custom field filtering on the invoice grid. For fields the AI cannot code with high confidence, the fallback is a structured human-in-loop review rather than a blank field: all fields predicted by Vic.ai carry a confidence icon color-coded from 0 to 1, with green above 0.80, yellow between 0.40 and 0.80, and red below 0.40, and up to three candidate values are predicted per field. Low-confidence predictions surface to AP staff for correction, and the AI learns from those human corrections, so that the next time a similar transaction occurs, it becomes more confident and the exception rate diminishes over time.

For a buyer coding dozens of NetSuite dimensions across 12,000 invoices a month, Stampli's AI engine (branded Billy) operates at stage 1 of the pre-processing journey (legitimacy and coding) and delivers line-level coding across the full dimension set the buyer describes. Billy codes invoices using the complete GL structure including accounts, departments, projects, classes, and custom dimensions, drawing from historical patterns to ensure accuracy and alignment with accounting policies. The NetSuite integration underpins this with full field fidelity: Stampli automatically mirrors any header or line-level custom field and can even map saved-search results into those fields, automapping new custom fields and managing them in Stampli so only relevant fields are posted back to the ERP with no re-engineering required. Tax fields are explicitly in scope: the system supports all tax scenarios and calculations, including international taxes by importing tax definitions created in NetSuite, and invoices can be coded more quickly and accurately because users only see valid value combinations in related fields. The per-customer learning model starts from onboarding: Billy automatically discovers workflows by analyzing trends and patterns in the first few days of usage, quickly identifying what coding is usually applied. Every correction the AP team makes feeds back into Billy's model: every time an adjustment is made to its suggestions, Billy learns and improves. For multi-line split scenarios, a complementary mechanism exists: Billy auto-generates suggested GL table templates based on recent invoices, reducing coding time, minimizing manual data entry errors, ensuring consistent application of accounting codes, and capturing tribal knowledge related to coding and allocations, with templates tailored to specific vendors for consistent coding. For fields Billy cannot code with confidence, the design is human-in-loop rather than leaving fields blank: Billy automates all routine, rule-based work while maintaining appropriate human involvement in judgment-based decisions and exception handling, delivering maximum efficiency without sacrificing control and accountability.

This buyer codes dozens of fields per invoice across GL account, location, department, class, project, several custom dimensions, and tax fields at line level, across 12,000 invoices per month, the exact failure mode their current header-only tool exhibits. Medius addresses this through SmartFlow, a proprietary CNN-based per-customer model that operates on what the engineering team describes as 'coding tables' (CTs) containing an 'unbounded number of coding lines,' with accuracy metrics computed 'per dimension with summation over lines': this is documented line-level, multi-dimension prediction, not header-level coding. Invoice coding is applied automatically by 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, including over 393 million from real-world human corrections on edge cases. The AI pipeline explicitly covers tax codes and cost centers as high-stakes fields, with 35-55%+ correction rates on those fields incorporated into training data. SmartFlow's modeling challenge is explicitly framed as handling 'an increasing number of predicted classes' and 'an unbounded number of coding lines in the table,' confirming the system predicts multi-line, multi-dimension coding tables rather than a single header-level code string. For fallback, invoices that do not receive a complete coding suggestion are routed to the 'New Invoice Review' queue for human coding, and the system allows invoices coded via coding suggestions to be automatically forwarded without manual review when confidence is sufficient. The material ceiling for this buyer is the NetSuite custom-segment layer: Medius holds 'Built for NetSuite' certification and extends NetSuite's P2P functionality, and provides fully managed integrations at the master data level with NetSuite, but no available documentation confirms that user-defined NetSuite custom segments (beyond standard department, class, location, and project dimensions) are automatically surfaced to and predicted by SmartFlow. A buyer with several custom dimensions must verify this mapping in implementation scoping.

For a buyer coding dozens of NetSuite dimensions across 12,000 invoices per month, Ramp's Smart OCR and auto-coding agent (both gated behind Ramp Plus) work in two separate passes. <First>, Smart OCR scans and parses invoices; for Ramp Plus customers, it uses AI and historical billing patterns to extract invoice details with greater accuracy, and the auto-coding agent automatically sets accounting fields on each line item. <Second>, the auto-coding agent sets accounting fields like GL category, location, and department on the bill and its line items, assessing the line item memo and amount and associating patterns from previous bills to predict coding with high accuracy. The documented scope of autonomous AI prediction covers four standard NetSuite dimensions: for every transaction the agent evaluates GL account, department, class, and location, stepping in when a field is blank and confidence is high. On the ERP integration side, Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding, and for each custom segment you want to view and code in Ramp, the segment must be viewable on the Credit Card, Bill, and/or Bill Payment Forms, with the appropriate permissions set for the Ramp Accountant Role. Tax fields are handled through a separate mechanism: you can set tax codes as default accounting coding on the vendor, and every new bill for that vendor will automatically apply that tax code to each line item; when synced, Ramp posts tax information at the line level in the Tax Details tab. Line-level splits are also available: line item splits on Bill Pay allow you to allocate the cost of a single line item across multiple accounting fields, including departments, locations, GL categories, and custom fields. The per-customer learning mechanism is vendor-specific: Smart OCR identifies the vendor, references historical invoices from that vendor, and applies saved custom instructions; the system learns from corrections and improves over time.

This buyer processes 12,000 invoices per month on NetSuite and requires AI-driven auto-coding across dozens of dimensions per line: GL account, location, department, class, project, multiple custom segments, and tax fields. BILL does offer an Invoice Coding Agent that operates at the line level, but its documented scope is bounded: the agent provides predictions for amounts, descriptions, and six specific coding fields per line, trained on the customer's historical coding behavior. The NetSuite sync matrix confirms that GL, departments, locations, classes, and project/jobs are supported as synced dimensions, but custom segments were added later as a separate feature capped at up to six segments synced between BILL and NetSuite. Two additional hard ceilings compound the problem for this buyer: first, BILL's own help documentation states that 'BILL does not allow for these classifications on payments or funds transfers' when location, department, or class are set as mandatory in NetSuite, forcing manual entry in NetSuite for those transaction types; second, the default payables classification (a header-level fallback) is applied to the general section of every bill when it syncs, meaning any dimension not coded in BILL arrives in NetSuite as a generic 'Unclassified' placeholder requiring reclassification. Tax fields are not named in the Invoice Coding Agent's documented six-field scope. The buyer's requirement for dozens of coding fields, several custom dimensions beyond six, and tax field AI coding exceeds what BILL's architecture currently delivers.

This buyer processes 12,000 invoices monthly on NetSuite with dozens of independent coding dimensions per line, which is precisely the scenario Medius's architecture is built for. The structural foundation is the configurable 'coding string': under System Configuration, the coding string for each company defines the composition of the account and other coding dimensions that together form a coding row. Each invoice carries multiple coding rows, and each row independently holds its own combination of dimension values, meaning GL account, location, department, class, project, and custom dimensions are not stamped from a single header code but are set independently per row. On top of this structure, Medius Capture learns after just two invoices, enabling Touchless Capture, and SmartFlow auto-fills coding, tax, and approver values for non-PO invoices with 95% precision after just two invoices. The AI pipeline that drives this is purpose-built for multi-line, multi-dimension throughput: Medius's AI is a multi-stage proprietary pipeline using Siamese CNNs for document classification, proprietary Markov models for line-item extraction, and CNN-based SmartFlow coding, trained on 2.4 billion-plus invoice field data points over more than 10 years of production. Critically, Medius measures SmartFlow precision in a '15 segments' variant: most often they use the variant of '15 segments,' which means 12 coding dimensions plus 2 tax codes plus first approver. This is an AI model measured across every dimension simultaneously per coding row, not just GL at the header. The capture layer is also explicitly line-level: Medius Capture captures both header and line level details, and Capture remembers corrections so the buyer does not have to repeatedly modify the result for future invoices. Learning occurs when users click 'Send to workflow' in Capture Verify, which is when the AI and ML engines activate before the invoice hits the workflow. For NetSuite specifically, Medius is a certified hybrid SuiteApp that extends NetSuite with procurement, AP automation, payments, and expense management, and the code plan imported from the ERP system is presented in Medius, with the ERP system serving as the master of all base registers. This means NetSuite's chart of accounts and dimension lists are the validation source for every coding suggestion. The buyer's fallback path is also addressed: when an invoice matches two coding suggestions, one with vendor and another with reference, these are combined, filling values from the first and supplementing with values from the second, so partial AI confidence on one dimension does not blank the entire coding row.

For a buyer running 12,000 invoices a month through NetSuite with dozens of coding fields per invoice, Vic.ai's AI operates at the line-item level, not the header. The FAQ documents that the system makes 10-25 predictions per classification or per line item on every invoice, and that line-item coding covers GL account splits, dimensions such as class, job, and location, and tax codes independently per line: "that translates to 10-25 predictions per classification or line item in every invoice we process" and "line item coding might include posting to a dimension such as class, job, or location, splitting items across many General Ledger accounts, and even recognition and coding of VAT and other taxes." The invoice-processing product page explicitly states that intelligent GL coding automates "the assignment of line items to the correct accounts and dimensions down to the most granular level," processing fields including "vendor, dates, numbers, cost accounts, dimensions, assets," and that "our AI can be trained on any header or dimension for complete customization." The per-customer learning model matters for this buyer's volume: when a buyer becomes a Vic.ai customer, the system goes through historical data training where it "learns from your team's past invoice processing actions," and the AI is intelligent enough to "predict all the values necessary to properly code an invoice from the header level fields... to the line item fields that are not explicitly on the invoice." The Q1 2026 product release added further line-level dimension specificity: "Auto-Apply PO Dimensions to Matched Invoice Lines: When an invoice line is matched to a PO, Vic.ai automatically applies the corresponding PO dimensions" and "Preserve Line-Level Dimensions in Document-Level PO Matching: For document-level matches, Vic.ai now maintains sub-group visibility of dimension and tax code variations when posting to the ERP," confirming that line-level coding propagates independently, not through header inheritance, all the way into NetSuite. The Autopilot feature processes invoices "without the need to ever touch or review them" once confident "both on the header and the line item level." After coding, "the invoice along with all the associated coding is pushed into the ERP system for payment" directly into NetSuite. This addresses pre-processing stage 1 (legitimacy and extraction) through the coding step that precedes ERP posting, and Autopilot handles those stages autonomously when confidence thresholds are met across all line-level fields.

This buyer processes 12,000 invoices per month on Oracle NetSuite and codes dozens of fields per invoice, with each line carrying a distinct combination of GL account, location, department, class, project, and custom dimensions. Stampli addresses this directly through its Billy AI engine and GL table template architecture. Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from the buyer's payment and accounting history. This is not header inheritance: coding happens at two levels; header-level coding applies values that affect the invoice as a whole, while line-level coding applies values to each distribution line, making it possible to split one invoice across multiple accounts, projects, cost centers, or legal entities. For recurring multi-line split patterns, Billy learns from recent invoices, and when it spots a pattern, automatically suggests GL table templates for approval, then fills in GL or item account lines when a template is applied and calculates individual line amounts based on the percentage defined on the template. On the NetSuite integration side, Stampli automatically mirrors any header- or line-level custom field and can map saved-search results into those fields, auto-mapping new custom fields and managing them so only relevant fields are posted back to the ERP. Stampli enables dynamic filtering of field values based on many-to-many relationships, such as entities, locations, vendors, GL accounts, and others, including custom fields. Billy can interpret all line types including items, general ledger, charges, and resources, syncing tax data and custom fields, while managing multiple subsidiaries, locations, and currencies. The AI model is per-customer adaptive: Stampli AI applies more than 83 million hours of AP and P2P experience and gets smarter with every action, learning from feedback, outcomes, and real-world changes. Fields the AI cannot confidently code are surfaced as exceptions for the AP team to resolve, rather than silently defaulting.

This buyer processes 12,000 invoices a month on NetSuite, coding dozens of fields per invoice at the line level, and needs each line to carry an independent combination of GL account, location, department, class, project, and custom dimensions. Ramp's Bill Pay does operate at the line level: its Smart OCR extracts line items (description, amount, quantity, unit price, type, tax rate), and its auto-coding AP Agent then sets accounting fields including GL category, location, and department independently on each extracted line item, learning from vendor-specific historical patterns. The auto-coding agent assesses each line item's memo and amount and associates patterns from previous bills to predict coding, and users can highlight additional invoice context (such as a ship-to address) to guide the agent on a per-vendor, per-field basis. For NetSuite specifically, Ramp imports all fields including custom segments and line-level custom fields, provided they are visible on the Bill form in NetSuite. However, two material ceilings apply for this buyer. First, the auto-coding agent and Smart OCR are exclusively available on the Ramp Plus tier; base-tier customers do not receive line-item auto-coding. Second, the agent's documented inputs are line item memo and amount, plus context manually highlighted from the invoice PDF; there is no evidence that the agent autonomously codes the full set of dozens of custom dimensions this buyer describes without human-highlighted context cues for fields beyond the standard GL, location, and department. The line-item splits feature (allowing a single line to be allocated across multiple accounting field combinations) is also a Ramp Plus-only capability. The NetSuite integration does carry line-level custom fields and custom segments when configured, avoiding the ERP glass ceiling problem for standard dimensions, but the auto-coding coverage across 'dozens of fields' per invoice remains undocumented at that breadth.

For a buyer processing 12,000 invoices a month with dozens of coding fields per invoice, BILL's AI engine (the Intelligent Virtual Assistant, or IVA) is documented to extract exactly five header-level fields from each invoice: vendor name, invoice number, invoice date, due date, and amount due. BILL's own help center FAQ confirms this scope explicitly, stating that 'machine learning algorithms will try to predict all five (5) required fields for creating the bill.' No dimension coding (GL account, location, department, class, project, or any custom dimension) is performed by IVA at the header level or the line level. Line-item splitting in BILL is a manual workflow: the AP user adds expense lines to a bill and assigns an account to each, with BILL's help documentation showing that dimension fields such as class, location, and department must be entered by hand per line. The NetSuite integration documentation makes the ceiling explicit: when bills sync from BILL to NetSuite, 'the general section of the bill will use the selections that are set as the Default Payables classification in the Bill.com Preferences,' and the official workaround is to set that default to 'Unclassified' or 'Uncoded' so that AP staff can identify records that still need reclassification inside NetSuite itself.

This buyer codes dozens of fields per invoice across NetSuite's native segments plus several custom dimensions, and needs all of them treated as first-class AI coding targets. Medius addresses this directly: 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. Those dimensions, once imported, are exposed to the SmartFlow AI engine: Medius AP Automation features SmartFlow, a powerful AI model that auto-fills coding, tax and approver values for non-PO invoices with 95% precision after just two invoices. SmartFlow operates across an unbounded coding table rather than a fixed column set: the modeling area handles an increasing number of predicted classes and an unbounded number of coding lines in the table. Medius's own precision benchmarks are measured against a default of 15 segments, meaning 12 coding dimensions plus 2 tax codes plus first approver, which already exceeds standard NetSuite classification fields and confirms custom dimensions are first-class targets. The integration itself is a "Built for NetSuite" certified SuiteApp, meaning it follows NetSuite platform development standards and best practices, and Medius has a fully managed integration to Oracle NetSuite so that master data is accurately transferred from the ERP application to Medius AP Automation. This places Medius at pre-processing stage 5 (cost allocation and dimension coding), with AI predictions written back to NetSuite as coded vendor bills.

For a buyer coding dozens of NetSuite fields per invoice including custom dimensions, Ramp's certified SuiteApp reads the buyer's live NetSuite schema and imports custom segments and custom fields as first-class coding targets alongside standard fields. The NetSuite overview documentation states: "Custom fields and segments: Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding." Setup requires granting the Ramp Accountant Role permissions per segment: for each custom segment a buyer wants to view and code in Ramp, the segment must be visible on Credit Card, Bill, and/or Bill Payment Forms, and the Ramp Accountant Role must be configured with full Value Management Access and Edit permissions — segments are then surfaced directly in Ramp's coding UI, not routed to a memo overflow field. Line-level custom fields are explicitly supported: line-level custom fields should be placed on the NetSuite expense tab to be available. The SuiteMarket listing (Ramp's official NetSuite app store entry) confirms: "Bring all of the tracking categories from NetSuite into Ramp, including NetSuite Custom Fields and Custom Segments, for simple transaction coding." On the AI coding side, Ramp's Accounting Agent automatically codes all relevant accounting fields using transaction context and history for entries the buyer typically populates when syncing to their ERP system; custom fields imported into Ramp are included in automations such as pre-coding cards and rules, and the Bill Pay auto-coding agent uses AI and historical billing patterns to set accounting fields on each line item for Ramp Plus customers. The written-back data flows to the correct NetSuite vendor bill fields: transaction-level fields sync as Subsidiary, Vendor, and body-level custom fields; expense-level fields sync as Account, department, class, location, customer, and any line-level expense custom fields.

This buyer codes dozens of fields per invoice in NetSuite, including native segments plus several custom dimensions, and needs those custom dimensions treated as first-class AI coding targets rather than overflow fields. Stampli's NetSuite connector, which holds Built for NetSuite certification and is tested quarterly, automatically mirrors both header-level and line-level custom fields from the buyer's live NetSuite schema with no re-engineering required: Stampli automatically mirrors any header or line-level custom field and can even map saved-search results into those fields, auto-mapping any new custom fields so only relevant fields are posted back to the ERP. Custom segments are explicitly enumerated alongside standard fields as a bidirectional sync target: the integration's sync manifest lists "Fields, Custom Fields/Segments" alongside Vendor List, GL Accounts, and Open PO/Line Items, and the product sheet states "Stampli can mirror any custom fields in NetSuite and map them to be used however they are today." On the AI coding side, Billy operates at line level across all configured dimensions including custom ones: Billy applies the organization's complete GL structure to every invoice, covering accounts, departments, projects, classes, and custom dimensions, with accuracy driven by pattern recognition and learned organizational logic. The learning mechanism is per-customer: Billy codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from the buyer's payment and accounting history, validating vendors and required fields and linking invoices to POs or receipts before anyone lifts a finger. Many-to-many validation also extends to custom fields during coding, meaning dynamic filtering of field values based on many-to-many relationships (entities, locations, vendors, GL accounts, and custom fields) ensures users only see valid value combinations in related fields. Competitors are explicitly called out for falling short: other providers like BILL and Tipalti either do not support customer-specific custom fields, have limitations on the number of supported fields, or require fields to be modified to map back, while Stampli supports existing custom fields directly, preserving the buyer's NetSuite configuration investments.

For a buyer coding dozens of fields per invoice including several custom dimensions, Vic.ai operates at pre-processing stages 1 (legitimacy/coding) and 2 (cost allocation via AI coding), with its core mechanism being an open 'dimensions' data model surfaced through a dedicated Dimensions API resource that can create, query, and sync dimension data to the connected ERP. The AI reviews and classifies invoice data, matching and processing all relevant invoice information 'including vendor, dates, numbers, cost accounts, dimensions, assets, and purchase orders.' At the line level, line item coding includes 'posting to a dimension such as class, job, or location, splitting items across many General Ledger accounts,' with both header and line item coding posted to the connected ERP. The AI model is per-customer: the AI can be 'trained on any header or dimension for complete customization,' and as it learns from the company's data 'Vic.ai gets smarter and more confident in its data predictions.' The Q1 2026 release added 'Auto-Apply PO Dimensions to Matched Invoice Lines,' 'Preserve Line-Level Dimensions in Document-Level PO Matching,' and 'Custom Field Filtering on the Invoice Grid,' confirming the schema extends to custom field types. However, the documented named dimension targets across all Vic.ai sources are consistently the standard NetSuite segments plus project and fund; one technical review explicitly identifies supported dimensions as 'Department, Location, Project, and Fund', and no source confirms that Vic.ai's NetSuite integration writes values back to NetSuite custom segment fields (those defined under Customization > Custom Segments, surfacing as custcol_xyz or custbody_xyz fields on the vendor bill record) as first-class, AI-predicted targets. The API payload shows an open 'fields' array with a 'custom:technician' example, but whether this maps to NetSuite custom segments on the bill record, rather than metadata fields within Vic.ai's own UI, is not confirmed in any available documentation.

This buyer codes dozens of fields per invoice in NetSuite, including multiple custom dimensions beyond the standard location, department, class, and project segments. BILL's NetSuite sync operates at a fixed field set that covers standard classifications only. <cite index='3-1,3-2'>BILL's own help center states: "Custom fields are ignored by the sync" and confirms that "custom fields will be preserved in Oracle NetSuite but will not be visible in Bill.com." The setup guide's accounting preferences configuration enumerates exactly which classifications can be enabled: <cite index='13-6'>"If using Departments, Locations, Classes, Customers, and/or Items on payables, choose Yes for that classification" — there is no mechanism to add custom segment columns beyond this fixed list. BILL's marketing integration page does claim to "sync your custom segments across bills and transactions," <cite index='21-1'>but this marketing claim is directly contradicted by the product's own help documentation, which governs the actual sync behavior. A third-party competitive analysis corroborates the limitation, characterizing <cite index='24-39,24-40'>BILL as "best for teams with very simple requirements and straightforward processes" and explicitly noting that "teams with more complex workflows and needs, would be smart to look elsewhere." This is the exact glass ceiling anti-pattern the buyer's requirement describes: BILL's data model maps only to NetSuite's standard fields, leaving every custom dimension invisible inside BILL and requiring the buyer's AP team to re-key those values directly in NetSuite after sync.

For a buyer processing 12,000 invoices per month on NetSuite with dozens of coding fields, Medius addresses the per-customer learning requirement through SmartFlow, its proprietary convolutional neural network (CNN) coding engine. Invoice coding is applied automatically by proprietary machine learning models, including Siamese CNNs for document classification and SmartFlow, a proprietary CNN that reaches 95%+ coding precision after just two invoices, trained on your historical actions and enriched by 2.4 billion+ invoice field data points across Medius's global customer base. The per-customer learning loop is operationally triggered at invoice confirmation: learning occurs when a user clicks 'Send to workflow' in Capture Verify -- that is when the AI and ML engines kick in, before the invoice hits the workflow. This means every AP team correction, approval, and dimension assignment feeds back into that specific customer's model instance. At the NetSuite integration layer, SmartFlow builds confidence in recognizing patterns; these templates can be assigned to specific suppliers, ensuring consistency and reducing manual intervention. Accounting templates are assigned to suppliers by users with the system role of Expense AP. As SmartFlow matures, it increasingly automates coding decisions, allowing invoices to bypass manual review and proceed seamlessly through the approval workflow. Crucially, this improvement is not just a global cross-customer effect: Medius achieves a 99.5% touchless rate for non-PO invoices, and these rates are not static -- they improve systematically with time and volume as Medius's models learn from each customer's unique coding patterns and correction signals. Dimensions are synchronized directly from NetSuite: Medius pulls dimensions directly from Oracle NetSuite, with the activation and management of specific dimension fields managed through the certified NetSuite SuiteApp integration. The model architecture is explicitly not a generic LLM: Medius uses a hybrid model architecture, where proprietary task-specific models handle the vast majority of invoice processing at high speed and low cost, while LLMs are selectively engaged only for edge cases such as unseen invoice layouts or new languages.

For a buyer processing 12,000 invoices a month on NetSuite with dozens of coding fields, Vic.ai addresses the per-customer learning requirement through a documented two-model architecture. The first model is a global AI trained on shared, anonymized invoice data across all customers; it handles header-level fields (invoice number, date, amount, currency) that are not buyer-specific. The second, called the 'Local AI model,' is where this requirement is met: this model is used to make predictions on invoice line-level coding fields that are unique to each buyer, such as GL account coding, location, and department, and it is trained using customer materials with learning not shared across clients. Onboarding begins with extensive historical data training where the system learns from the buyer's past invoice processing actions, and the loop continues post-deployment: the AI continuously improves through a feedback loop that enhances accuracy and confidence each time a user reviews and adjusts an invoice. Even without prior company data, the model quickly learns from user feedback, and each correction by the AP team helps the AI adapt to the organization's unique GL setup. At the field level, Vic.ai automatically extracts and processes data at both the header and line-item level, automating assignment of line items to the correct accounts and dimensions down to the most granular level. The system surfaces per-prediction confidence scores: transparent confidence scoring shows the AI's prediction confidence at the header and line-item levels to indicate accuracy of each data point, and finance teams can configure autonomy thresholds based on this score, defining rules such as autonomously posting invoices above a 95% confidence threshold while flagging lower-confidence items for human review. The vendor also confirms that accuracy translates to 10-25 predictions per classification or line item in every invoice, and improves naturally over time because the algorithms are trained by receiving more corrections, generating a positive feedback loop.

For a buyer processing 12,000 invoices a month with dozens of coding fields across Oracle NetSuite, Billy operates a per-organization learning loop that directly addresses this requirement. The core mechanism is documented on Stampli's own P2P product page: Billy codes invoices using the buyer's complete GL structure including accounts, departments, projects, classes, and custom dimensions, drawing from historical patterns, with each field coded through pattern recognition and learned organizational logic. The learning is explicitly tied to the buyer's own transaction history: Billy codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from the buyer's payment and accounting history, and gets smarter with every action by learning from feedback, outcomes, and real-world changes. Corrections are the primary feedback signal. Stampli's "Billy is Different" page states: once the buyer provides guidance or correction, Billy incorporates that feedback into its permanent knowledge base, applies the learning consistently across all similar future situations without requiring repeated instruction, and one correction teaches the entire system, improving every future transaction. The ramp curve is documented: Billy immediately begins processing invoices from established vendors and flagging duplicates; within the first few weeks it expands to suggest appropriate coding and multi-level approval workflows; by month one its learning continues to expand, allowing it to manage more and more of the work. On the feedback loop architecture specifically, any necessary corrections contribute to Billy's continued learning, creating a feedback loop that becomes part of the feedback loop for future transactions. For fields the model cannot code with confidence, Billy uses machine learning to figure out which codes to use, but if it encounters an item where it does not know the code, it makes a suggestion and flags the code for a member of the AP team to check. Billy also provides a complementary structured mechanism alongside AI learning: Billy learns from recent invoices and automatically suggests GL table templates for approval when it spots a pattern, and vendor-specific templates can be created for consistent coding tailored to invoices from a particular vendor.

For a buyer running 12,000 invoices a month with dozens of NetSuite coding fields, Ramp's per-customer learning operates through two documented layers in Bill Pay (stage 1 through stage 2 of pre-processing). First, for Ramp Plus customers, Smart OCR uses AI and historical billing patterns to extract invoice details with greater accuracy, and the auto-coding agent automatically sets accounting fields on each line item. Second, the learning feedback loop is customer-specific: codings are suggested based on your team's historical coding patterns, transaction-level detail, and any incorrect suggestions corrected in the past; upon making a correction, a feedback prompt allows entry of natural-language context as to why the change was made, and this context informs the model's learning and influences future coding decisions. At the Bill Pay line-item level, the auto-coding agent assesses the line item memo and amount and associates patterns from previous bills to predict coding for the bill with high accuracy. For NetSuite custom dimensions specifically, Ramp can import most custom fields into Ramp for coding, and these custom fields function similarly to standard fields in Ramp. The vendor-history anchor is explicit: the AP Agent automatically assigns the correct accounting codes and categories to your invoice line items based on vendor historical patterns and provided invoice context. However, there is a documented ceiling on field coverage: Ramp auto-codes any field your business uses for all transactions, but does not auto-code fields like Customer or Project if they apply only to some expenses. For a buyer with dozens of coding fields, many of those dimensions will be conditional rather than universal, and those fields fall outside the auto-coding scope by design.

This buyer processes 12,000 invoices per month on NetSuite and codes dozens of fields per invoice, including multiple custom dimensions. BILL's Invoice Coding Agent does incorporate organization-specific history into its predictions, but the mechanism is shallow relative to this requirement. The agent creates predictions by analyzing two primary sources: historical patterns, where it reviews up to five of the most recent bills for a specific vendor to identify the organization's unique coding habits, and document analysis, where it pulls data directly from newly uploaded bill documents to compare predictions with current billing details. The Transaction Agent (for spend and expense) goes slightly further: it uses merchant data, the company's coding history, and receipt details to automatically fill in transaction fields, and it learns from the team's corrections to get more accurate over time. However, the foundational model underneath is explicitly cross-customer, not a tenant-isolated per-customer model: it is trained on more than 250 million bills and draws on insights from over $1 trillion in payment transactions and more than one billion documents across nearly 500,000 customers. The per-customer adaptation is a recency-based lookup (last five bills per vendor), not a continuously trained model that isolates this buyer's full historical GL and dimension assignments and updates as new approvals accumulate. Critically, the agent provides line-item coding predictions for amounts, descriptions, and six specific coding fields, which is a hard ceiling well below the dozens of fields this buyer requires. Choosing the correct GL account, department, class, or location is cited as the scope of complexity the agent addresses, with no documented support for the buyer's several custom NetSuite dimensions, tax fields, project codes, or cost centers in the AI coding layer.

For a NetSuite buyer coding dozens of dimension fields across 12,000 monthly invoices, Vic.ai's mechanism works as follows: upon ingestion, the AI generates predictions for virtually every field on the invoice, at both header and line-item level, including GL account, location, department, class, custom dimensions, and tax fields. The AI makes predictions for almost all invoice fields in two ways: a Confidence Indicator and a Prediction table. Every predicted field carries a color-coded confidence icon ranging from 0 to 1: green above 0.80, yellow between 0.40 and 0.80, and red below 0.40. Up to three ranked values are predicted per field, each with its own confidence score. This means no field is silently dropped or left blank: the reviewer always sees a pre-populated invoice with best-guess suggestions and a visual signal of confidence on every dimension. Intelligent GL coding automates assignment of line items to the correct accounts and dimensions at the most granular level, with prediction confidence scores visible at both header and line-item levels. The AI can be trained on any header or dimension for complete customization. However, the routing unit is the whole invoice, not the individual field. Autopilot, Vic.ai's autonomous-posting mode, requires an accuracy rate of 95 to 100 percent across all predictions, including GL accounts and any dimension such as Customer, Location, Class, or Department. When any single field falls below that threshold, the invoice does not qualify for Autopilot and is routed to an AP reviewer for the full invoice, not just the low-confidence dimension. The AP staff reviews predictions made by the AI and confirms whether they are correct or makes edits as necessary, and the AI learns from these interactions, improving accuracy over time. The intent is that only transactions where AI confidence on a prediction is low ever need to be examined, with the remainder of the invoice not needing to be touched. In practice, that attention-focusing happens visually within the full-invoice review screen, not through a field-scoped routing mechanism that isolates and queues only the uncertain dimensions.

For a buyer coding dozens of NetSuite dimensions per invoice at 12,000 invoices per month, Stampli's Billy AI operates at the coding screen before any human touches the invoice: it pre-populates fields line by line, applying GL accounts, departments, cost centers, and custom dimensions learned from the organization's payment and accounting history, and surfaces those suggestions inline on the invoice rather than in a separate reporting dashboard. Billy codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from your payment and accounting history, and validates vendors and required fields before anyone lifts a finger. For fields where Billy's confidence is insufficient, the documented design principle is explicit flagging rather than silent omission: when Billy isn't confident about something, it flags it for human review rather than guessing. Real users confirm the partial pre-population model: pre-coding of invoices saves time even if there are some changes or specific details that need to be entered manually. Corrections feed back into Billy's model: every time you adjust its suggestions, it learns from you, and gets that much better. However, the specifically granular sub-requirements of this buyer (a per-field numerical confidence indicator displayed inline, and a field-scoped exception queue routing only the unresolved dimension fields rather than surfacing a flagged invoice for full review) are not confirmed in product documentation or help-center articles; one user explicitly requested a confidence rating alongside AI suggestions as a feature, implying it is not presently a labeled UI element.

For a buyer coding dozens of NetSuite dimensions per invoice, Medius's exception fallback works at the invoice level, not the field level. SmartFlow, a CNN-based AI model, attempts to auto-populate all coding dimensions for each non-PO invoice; as SmartFlow matures, it increasingly automates coding decisions, allowing invoices to bypass manual review and proceed seamlessly through the approval workflow; if automatic coding is successful, the invoice moves forward. When coding does not fully succeed, the invoice falls to a 'New Invoice Review' queue: the system will send the invoices as far into the system as possible, and only the invoices that need manual handling will end up in New Invoice Review. Critically, Medius supports incomplete coding suggestions via the `AllowIncompleteAllocationProposal` parameter, which means incomplete coding suggestions can be created, allowing fields that are mandatory according to coding rules to be left empty — so the reviewer sees a partially pre-populated invoice rather than a fully blank one. A fallback hierarchy also applies: if a coding suggestion is missing, the previous allocation is applied to the invoice via `UseFrequentAllocationProposal`. The AI pipeline itself uses tree-based ensembles for confidence scoring and CNN-based SmartFlow coding, trained on 2.4 billion+ invoice field data points. However, no evidence exists that per-field confidence scores are surfaced as visual indicators in the reviewer's coding UI, nor that only specific low-confidence dimension fields are flagged and isolated for review while high-confidence fields are committed autonomously. The exception unit is the whole invoice, not the individual dimension.

For a buyer coding dozens of NetSuite dimensions per invoice at 12,000 invoices per month, Ramp's Bill Pay auto-coding agent (available on Ramp Plus via Smart OCR) addresses this requirement partially. The agent reads line-item memos and amounts, references historical billing patterns, and fills GL category, location, department, and similar fields on each bill line item; hovering over any coded field reveals how it was set. For fields the agent cannot code, the bill draft remains with those fields blank and the AP reviewer completes them manually before submission. On the card transaction side, Ramp's documentation is more explicit: high-confidence suggestions auto-populate the cell and move the transaction to Ready to Sync, while medium-confidence suggestions surface in the cell's dropdown in the Needs Review tab, giving reviewers a pre-populated best guess. To identify how an accounting field was set, users hover over the field; if additional invoice context would help drive coding, users can highlight text on the invoice PDF to assist the agent in selecting the appropriate coding. Approvers can resolve incomplete fields in-workflow without restarting: when enabled by an admin, approvers can edit most bill fields directly during the approval process, including adjusting dates, modifying line items, applying splits, and updating accounting fields, without needing to reject and resubmit the bill. However, there is no documented Bill Pay-specific mechanism that isolates each uncoded dimension as a named, routed exception with a per-field confidence indicator and structured reviewer task assignment scoped to only those fields.

For a buyer running 12,000 invoices a month on NetSuite with dozens of coding fields per invoice, the requirement is that the AI surface a per-field confidence indicator, pre-populate a best-guess for every dimension it cannot code with certainty, and route only those specific unresolved fields to an AP reviewer. BILL's current AI layer, the Invoice Coding Agent, presents all predictions on a single bill entry screen where the user reviews and modifies any field; predictions are displayed on the bill entry page, are not final until approved by a user, and customers can manually modify any field pre-filled by the agent. Critically, the agent provides line item coding predictions for amounts, descriptions, and six specific coding fields, with GL account, department, class, and location named as the fields the agent targets. No evidence exists in any BILL documentation of per-field confidence scores surfaced in-workflow, a field-level exception queue that isolates individual unresolved dimensions, or a routing mechanism that commits high-confidence fields while escalating only uncertain ones. The interaction model is a whole-invoice review: extracted information is highlighted and can be viewed side-by-side with the original invoice so the user can review, accept, or revise; missing or incorrect information can be corrected with a single click. That is a manual-correction overlay, not the field-level exception routing with confidence indicators the buyer requires.

This buyer runs roughly 12,000 invoices a month against a NetSuite schema that spans GL account, location, department, class, project, several custom dimensions, and tax fields, with splits at the line level: exactly the depth where most AP tools stop at header coding and force manual entry for everything else. Stampli's AI (Billy the Bot) operates at the line level, not just the header: Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from your payment and accounting history; it validates vendors and required fields, flags duplicates, and links invoices to the right POs or receipts. On the NetSuite integration side, Stampli automatically mirrors any header or line-level custom field and can even map saved-search results into those fields, automapping new custom fields and managing them in Stampli so only relevant fields are posted back to the ERP. Tax fields are also included: Billy can interpret all line types, including items, general ledger, charges, and resources, and syncs tax data and custom fields. The AI learning model is customer-specific: once Billy understands your workflows, it automates these processes, including suggesting routing workflows for approval, pre-filling coding fields based on past data, and flagging invoices that don't fit established patterns for further review. For complex multi-line allocations, Billy auto-generates suggested templates based on recent invoices, and templates can be tailored to specific vendors with context-aware selection so coders only see templates relevant to the invoice they are working on. However, the buyer's requirement is not only that the fields be coded at line level: it is that Stampli can produce a measurable, field-by-field autonomous coding rate against the buyer's specific schema. Stampli's published metric is 87% of finance work on average across 2,700+ unique fields, trained on $150B+ in annual spend across 70+ ERPs. That aggregate stat does not decompose to a per-field hit rate (e.g., what percentage of the buyer's custom dimension field is auto-coded versus suggested versus left blank), and no published Stampli documentation produces a field-by-field coverage report specific to a customer's NetSuite schema. A user review corroborates the general direction: the AI Agent within Stampli has started to predict each field being captured, making the job much easier, but this is anecdotal, not a measured per-field rate.

A buyer processing 12,000 invoices per month with dozens of NetSuite coding fields sits squarely in Vic.ai's stated target use case. Vic.ai's AP Autonomy platform operates at pre-processing stage 1 (legitimacy and coding) and the model makes predictions on two aspects of every invoice: header-level data (invoice number, due date, terms, amount, currency) and line-item level data (GL Account, location, department). The vendor's invoice processing product page extends the scope further, stating that invoice data is reviewed by AI down to the line-item level, covering fields such as vendor, dates, numbers, cost accounts, dimensions, assets, and POs, and that the AI can be trained on any header or dimension for complete customization. Confidence scoring operates at the data-point level: the platform surfaces AI prediction confidence scores at the header and line-item levels to indicate the accuracy of each data point, and Vic.ai's explainable AI (XAI) system uses red, yellow, or green bars to indicate the confidence range for how accurate extracted invoice data points are. The Autopilot gate requires full-field confidence: Autopilot means all invoice details are predicted with 95% or greater confidence, allowing invoices to move straight to approval without any data entry or classification review. The per-customer learning model is documented: AP staff reviews predictions and confirms or edits them, and the AI learns from these interactions and improves its accuracy over time. However, the publicly documented field examples name only GL Account, location, and department at the line level. The buyer's schema also requires class, project, tax fields, and several custom NetSuite segments. The vendor states the AI can be trained on 'any dimension,' but no public documentation enumerates a field-by-field coverage rate against a specific NetSuite schema, nor does any published metric break down autonomous coding rates by individual field. The published accuracy claims — 97-99% AI accuracy and 85% no-touch rate by month 6 — are invoice-level rates, not per-field coverage rates across the buyer's specific dimensions.

For a buyer coding dozens of fields per invoice in NetSuite, including GL account, location, department, class, project, several custom dimensions, and tax fields, Medius's AI coding engine is called SmartFlow. SmartFlow is Medius's machine learning solution for Automatic Coding Suggestion, designed to save accountants time by predicting GL coding values. SmartFlow builds confidence in patterns assigned to specific suppliers via accounting templates, and as it matures it increasingly automates coding decisions, allowing invoices to bypass manual review and proceed seamlessly through the approval workflow. The critical technical constraint surfaces in Medius's own engineering blog: the number of dimensions SmartFlow handles varies between tenants from 2 to 12, and it may even differ among coding lines within a single invoice. Medius uses accuracy, precision, recall, and Coding Rate as internal KPIs, evaluated in the variant of '15 segments,' meaning 12 coding dimensions plus 2 tax codes plus first approver. The NetSuite connector does pull dimension master data from Oracle NetSuite, and dimensions are sourced directly from Oracle NetSuite with the activation and management of specific configurations. However, no public documentation confirms that buyer-defined NetSuite custom segments (created via SuiteGL/SuiteCloud) are included as live targets in SmartFlow's predictive model rather than merely passed through as mapped fields. The buyer's requirement asks for a demonstrable, field-by-field autonomous coding rate against their specific schema. While Medius does define per-dimension KPIs internally (precision, recall, Coding Rate), the modeling area is complex due to an increasing number of predicted classes and an unbounded number of coding lines, and the challenges extend beyond machine learning predictive design into analytics. No evidence exists of a buyer-facing dashboard that produces a field-coverage breakdown scoped to the buyer's actual NetSuite dimension schema rather than Medius's internal 15-segment benchmark.

For a buyer coding dozens of NetSuite dimension fields per invoice across 12,000 monthly invoices, Ramp operates through two distinct layers. The first is Smart OCR (Ramp Plus), which extracts invoice content fields at the line level: description, amount, quantity, unit price, and tax rate. Smart OCR extracts and auto-fills bill details and line items, while accounting coding fields like GL category, department, and location are handled separately by the auto-coding agent. The second layer is the AP auto-coding agent, which applies learned logic to dimension fields: using AI and historical data, Ramp's Bill Pay auto-coding agent automatically sets accounting fields like GL category, location, and department on the bill and its line items, assessing the line item memo and amount and associating patterns from previous bills to predict coding. For the NetSuite field model specifically, Ramp syncs both transaction-level and line-level custom fields from NetSuite, including subsidiary, vendor, account, department, class, location, and any additional custom fields enabled, which can be automatically populated using Ramp's coding rules. On custom segments, Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding. The accounting agent's field scope is documented as: for every transaction, the agent evaluates GL account, department, class, and location and steps in under these conditions: blank field plus high confidence means AI takes the first pass and fills it. Custom dimensions beyond those four are coded only when historically frequent: all fields that have historically been frequently used to code transactions will be coded. Ramp's published aggregate benchmark is 85% of accounting fields right the first time, based on internal data collected in September 2025 evaluating the number of accounting fields successfully auto-coded by the Ramp agent. The critical gap for this buyer's requirement is that this 85% figure is a cross-customer aggregate, not a per-field, per-customer breakdown. There is no mechanism documented by which Ramp can demonstrate, before deployment, what percentage of the buyer's specific fields (GL, location, department, class, project, each custom dimension, tax fields) will be autonomously coded versus requiring human input. Tax field automation is noted as a separate beta capability: Ramp now helps automate tax code selection for NetSuite and QuickBooks Online users by analyzing receipts (Beta). One additional structural ceiling applies: conditional filtering does not support auto-coding; users cannot auto-code a transaction based on specific inputs. This means any buyer field whose options depend on another field's value will not be auto-coded by the agent.

For a buyer running 12,000 invoices a month on NetSuite with dozens of coding fields per invoice, BILL's AI operates at a thin slice of that schema. BILL's own NetSuite integration page commits to 'AI-enabled invoice coding and duplicate invoice detection,' and its SuiteApp datasheet states that 'AI-enabled technology extracts invoice information to create a bill with accuracy, that improves over time.' The fields BILL can capture and pass through the sync are the standard NetSuite chart-of-accounts fields: vendor, amount, due date, GL account, and line-item descriptions. BILL's help center documentation confirms that location, department, and class fields are present as sync objects (evidenced by dedicated sync error articles for those exact fields), but the sync architecture is a subset integration: BILL maps its own internal field set to NetSuite's standard fields, and custom segments, project dimensions, and any buyer-defined custom fields are not part of BILL's data model. The buyer's requirement for per-customer AI learning that covers the full schema, including custom dimensions, tax fields, and line-level splits across all dimensions, cannot be met because BILL's data model does not carry those fields at all, meaning the AI has no surface to code them against.

For a buyer coding dozens of fields per invoice on NetSuite, including GL account, location, department, class, project, and several custom dimensions at line level, Stampli's integration is purpose-built to handle exactly this data model. The mechanism works as follows: Stampli connects to NetSuite via a token-based API and automatically syncs master list data including GL accounts, vendors, locations, subsidiaries, open POs with line-item detail, and custom fields and segments, refreshing critical lists every five minutes with near-real-time bill posting. On the coding side, Billy the Bot applies learned coding suggestions line by line across GL accounts, departments, and custom dimensions drawn from the buyer's own payment and accounting history, so the AP workspace surfaces every dimension that exists in the buyer's NetSuite instance as a coding target. Critically, Stampli's integration carries both header-level and line-level custom fields: <cite index='16-3,16-16,16-17'>Stampli automatically mirrors any header or line-level custom field and can even map saved-search results into those fields, auto-mapping new custom fields and managing them in Stampli so only relevant fields are posted back to the ERP with no re-engineering required. The integration explicitly names custom fields and segments alongside subsidiaries, projects, departments, and warehouse fields in its sync manifest: <cite index='29-4,29-5,29-6,29-7,29-8'>the SuiteApp.com data sheet lists 'Fields, Custom Fields/Segments (e.g., Project, Dept, Warehouse, etc.)' in the sync-lists schema, confirming that Stampli mirrors any custom fields in NetSuite and maps them to be used however they are today. On intercompany and subsidiary dimensions specifically, <cite index='7-17,7-18,7-19,7-20'>Stampli uses the same intercompany fields from NetSuite, fully supports NetSuite OneWorld account functionality for multiple subsidiaries under a single account, and mirrors intercompany fields so transactions can be processed in Stampli and posted back to NetSuite. For tax fields, <cite index='6-5'>whether a customer is still on Legacy Tax or has migrated to SuiteTax, Stampli reads, writes, and calculates every tax scenario, domestic or international, so AP can stay compliant without switching tools. Many-to-many filtering prevents invalid combinations: <cite index='7-5'>Stampli enables dynamic filtering of field values based on many-to-many relationships including entities, locations, vendors, GL accounts, and custom fields, so only valid combinations of values are presented. The write-back path is fully bidirectional: <cite index='18-1,18-2'>Stampli can mirror custom fields from NetSuite and map them exactly as they are used today, and the system automatically maps new custom transaction body fields and line fields inside Stampli so only relevant fields are sent back to the ERP. The BFN certification, tested quarterly, provides structural assurance that this fidelity survives NetSuite's biannual releases: <cite index='28-3,28-4,28-5'>this designation is granted by NetSuite to third-party SuiteApps that meet its standards for security, quality, and performance, confirming that Stampli has been reviewed and tested quarterly to ensure continued compatibility as the ERP evolves, with no middleware changes required. For a buyer at 12,000 invoices per month, <cite index='10-2,10-3'>Stampli automatically synchronizes essential master list data including GLs, vendors, POs, receiving, and any custom field, and supports unlimited entities. The AI model learns coding patterns from the buyer's own history: <cite index='a6d103f4'>Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from the buyer's payment and accounting history.

This buyer codes dozens of fields per invoice across GL account, location, department, class, project, several custom dimensions, and tax fields at the line level, then needs all of them to write back correctly to NetSuite at 12,000 invoices per month. Vic.ai's AP Autonomy module connects directly to NetSuite via a real-time, bi-directional integration: after approval, the invoice along with all the associated coding is pushed into NetSuite for payment. The AI processes all relevant invoice information, including vendor, dates, numbers, cost accounts, dimensions, assets, and purchase orders. The Q1 2026 product release provides the most specific integration fidelity evidence available: Vic.ai now maintains sub-group visibility of dimension and tax code variations when posting to the ERP, and finance teams can filter invoices by configured custom fields for faster segmentation and reporting. The same release added auto-application of PO dimensions to matched invoice lines. However, no Vic.ai documentation explicitly catalogs which NetSuite custom segments (cseg_ fields), custom lists, or intercompany dimensions are exposed as coding targets in the AP layer, nor confirms that the integration carries the full SuiteCloud custom segment data model rather than a standard-fields subset. The Q1 2026 note that line-level dimension and tax code preservation was a new enhancement implies this capability was incomplete or absent in earlier releases, and no source confirms coverage of every custom segment a given NetSuite instance may be configured with.

This buyer codes dozens of NetSuite dimensions per invoice at 12,000 invoices per month, requiring an AP layer that carries the full NetSuite data model without loss. BILL's NetSuite integration operates as a SuiteApp-based bidirectional sync. The bidirectional sync handles vendors, charts of accounts, departments, classes, locations, subsidiaries, unpaid bills, purchase orders, payments, vendor credits, funds transfers, and supporting documents. Beyond those standard dimensions, BILL strengthens controls with 2- and 3-way PO matching that automatically syncs back into NetSuite, and syncs custom segments across bills and transactions to preserve the buyer's unique NetSuite setup. A BILL help center article titled "Oracle NetSuite sync: custom dimensions" (article 000003774) exists and confirms the topic is formally documented, though its body content was not accessible during this evaluation. The SuiteApp datasheet confirms BILL supports NetSuite OneWorld, so buyers can manage payables across multiple U.S. NetSuite subsidiaries, business units, and legal entities. Tax field coverage is partially addressed: BILL supports NetSuite SuiteTax so transaction tax details are included on invoices synced from NetSuite. However, the integration's documented scope covers standard segments plus custom segments "when properly configured" but stops short of confirming that every custom list type, every custom segment at the transaction line level, and every intercompany dimension in a complex enterprise NetSuite instance writes back at the correct field level. BILL is the dominant player in SMB and lower mid-market AP automation, integrating with NetSuite via SuiteApp and providing invoice capture, approval routing, and ACH/check payments, but market analysis consistently identifies it as a fit for simpler configurations rather than enterprise-scale multi-dimension instances.

This buyer codes dozens of fields per invoice at 12,000 invoices per month, including custom segments, custom lists, and intercompany dimensions that sit beyond NetSuite's standard GL account, department, class, and location fields. Medius delivers its NetSuite connectivity through a certified hybrid SuiteApp: the Medius for Oracle NetSuite SuiteApps carry 'Built for NetSuite certification,' meaning they follow platform development standards and best practices. The integration is positioned as a rapid-deployment package: it is 'a certified hybrid SuiteApp that extends NetSuite with procurement, AP automation, payments, and expense management,' and Medius Connect 'enables rapid deployment with no consultants or custom coding required.' At the coding layer, Medius's AI handles matching, coding, and routing, and the fact sheet claims 95% precision after just two invoices so the team only touches genuine exceptions. However, neither the fact sheet, Medius's help center documentation, nor any marketing material found via web search specifies which NetSuite field types the connector surfaces as coding targets: the published material does not confirm that custom segments, custom lists, intercompany dimensions, or tax fields configured in the buyer's specific NetSuite instance are imported as available dimensions and written back at the correct field level. The 'no custom coding required' and 'rapid deployment' positioning is consistent with a standardized-subset connector that covers standard NetSuite fields, which for a buyer with this field depth means the AP layer may not carry the full data model and the team would be forced back to manual ERP entry for uncovered dimensions.

For a buyer running 12,000 invoices a month across dozens of NetSuite dimensions, Ramp's integration operates through a native SuiteApp (REST + SOAP web services, token-based authentication) and covers an impressively broad range of NetSuite's data model. At the transaction level, Ramp syncs Subsidiary and Vendor; at the expense (line) level, it syncs Account, Department, Class, Location, Customer, Billable status, and line-level expense custom fields. Transaction-level fields include Subsidiary and Vendor with body-level custom fields; expense-level fields include Account, Department, Class, Location, Customer, and Billable, as well as any line-level expense custom fields. Custom segments are explicitly supported: Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding, though each segment must be permission-granted to the Ramp Accountant Role and made visible on the Bill form in NetSuite before Ramp can detect and code it. For each custom segment you want to view and code in Ramp, the segment must be viewable on the Credit Card, Bill, and/or Bill Payment Forms, and specific permissions must be set for the Ramp Accountant Role. Tax dimensions are covered at depth: Ramp pulls in the tax codes set up in NetSuite and presents them as options for transactions, bills, and reimbursements, and now supports both NetSuite's SuiteTax and Legacy Tax products. When SuiteTax is enabled, Ramp syncs tax line detail on bills to NetSuite, ensuring tax amounts are accurately recorded and available for reporting. For multi-subsidiary configurations (NetSuite OneWorld), Ramp maintains separate setup paths and entity-level payment settings. Ramp supports multi-entity businesses for NetSuite customers, and customers can add all business entities with a single Ramp account and set different payment settings for each entity. Inter-company journal generation is also documented for international transactions. Ramp's international accounting support for NetSuite automates and streamlines global transactions, accurately matching credit card transactions with the correct tax code, calculating foreign exchange fees, and generating inter-company journals when needed. The material ceiling for this buyer's 'dozens of fields' scenario is the custom field type constraint: to display custom fields in Ramp, they must be set up to select a single value from a custom list or record. Free-text custom fields and multi-select fields are not supported for rules or AI auto-coding. Card-level rules are only supported for single-select fields; rules for free-text fields are not supported at this time. Additionally, the documentation qualifies its own coverage: Ramp can import most of your custom fields into Ramp for coding, which leaves an unspecified subset of field configurations that may not transfer. Header-level segmentation on bill payments requires an additional SuiteBundle deployment: this bundle fixes the 'Please enter value(s) for: Location/Account/Vendor/Department' sync error that occurs when customers require segmentation on transaction headers. All advanced AI coding, Smart OCR, and accounting agent features are gated behind the Ramp Plus tier.

For a buyer running 12,000 invoices per month across dozens of NetSuite coding fields, Medius Analytics delivers two relevant but non-intersecting reporting layers. First, the platform's Gadget framework includes a dedicated touchless-ratio-per-supplier view: it "displays the ratio of touchless invoices per supplier and invoice type" and is explicitly designed so AP managers can "quickly spot touchless processing bottlenecks on suppliers" and "improve workflow automation for suppliers with low touchless ratio." Second, the Medius Analytics Capture dashboard extends this to the supplier level with trend data: it provides "rich insights into your touchless Capture rates" through a dashboard that includes "drill-down views into the individual supplier level" and supports "a blend of operational and strategic level reporting." Third, the First Time Right dashboard adds an invoice-quality layer per supplier: it lets AP managers "easily identify and track changes made to invoices" and "pinpoint which suppliers are sending invoices with incorrect information." The coding model itself is measured internally across multiple dimensions: Medius uses both micro and macro KPIs including "accuracy, precision, and recall, as well as Coding Rate" measured in a "variant of '15 segments,' which means 12 coding dimensions + 2 tax codes + first approver." However, the buyer's specific requirement asks for the intersection of three variables simultaneously: per vendor, per individual coding field (GL, department, class, location, project, custom NetSuite dimensions), and a three-way segmentation of outcomes (fully auto-coded, partially coded requiring human completion, fully manual). The per-supplier touchless rate gadget reports at the invoice level, not the individual field level. Medius surfaces "comprehensive, real-time analytics on invoice status, exception rates, cycle times, and cost per invoice" but no documented customer-facing report exposes the coding-source attribution (AI vs. human) broken out per field for each vendor in a single view. The internal 15-segment coding KPI model suggests this data exists in the platform's data layer, but it is not confirmed as a self-service operational report available to AP managers.

For a buyer coding dozens of NetSuite dimensions across 12,000 invoices per month, Ramp offers field-level coding source attribution at the individual bill level but not the aggregate, per-vendor, per-field coverage dashboard the requirement describes. Within the Bill Pay OCR interface, hovering over any auto-filled coding field surfaces a tooltip that identifies how the value was set: extracted from the invoice, learned from past bills, or manually entered. A tooltip shows the source, such as whether the value was extracted from the invoice, learned from past bills, or applied from a saved instruction; if a value was manually entered, the tooltip displays 'Manually edited' instead of a source attribution. This mechanism exists at the field level but does not roll up into a reporting view. Ramp's reporting module, available under Insights, supports custom reports and dashboards built around spend, bill status, and payment dates, and allows saving, sharing, and exporting. Users can build saved reports, organize them into dashboards, and track spend across Cards, Reimbursements, and Bills, and can reuse saved reports, share individual reports with teammates, and export report data. However, neither the real-time reporting help article nor any Bill Pay analytics documentation describes a report type that aggregates coding source (AI vs. manual) per vendor, per coding field, or surfaces auto-code coverage percentages or trend lines over time. The closest operational analytic Ramp documents is the controller-facing practice of reviewing accuracy rates, refining rules, and handling edge cases where automation flags low confidence, but no dedicated dashboard module is documented to deliver this. The per-field tooltip provides the raw signal, but the requirement asks for that signal aggregated into a measurable operational lever across all NetSuite dimensions at 12,000-invoice-per-month scale, and that aggregated view is not documented.

For a buyer processing 12,000 invoices per month across dozens of NetSuite dimensions, Stampli Insights (the vendor's reporting and analytics module) provides 12 pre-built reports with real-time data across the invoice lifecycle, plus interactive dashboards that can be filtered by vendor, entity, and other key metrics. The Insights page explicitly states users can 'drill down into any datapoint, including standard fields, custom fields, and GL accounts, for deeper analysis,' and all report data can be exported to CSV or XLSX for offline analysis. Dashboard views include invoice lifecycle timing, user productivity (coders and routers with most rejections, approval time trends), and vendor-specific metrics such as invoice lifecycle times. What is not documented anywhere in Stampli's product pages, help center, or marketing materials is a purpose-built report that (1) classifies each invoice outcome as fully auto-coded, partially coded requiring human completion, or fully manual; (2) segments those outcomes by vendor AND by individual coding field (GL account, department, class, location, project, custom dimension); or (3) tracks the percentage improvement in AI coding coverage over time as Billy's per-customer model learns. User reviews corroborate this gap directly: one Capterra reviewer specifically requests the ability to 'run reports per vendor and per cost code,' and competitive analysis sources note user frustration that Stampli does not allow custom reports built to specific criteria without manually exporting and merging multiple built-in reports.

For a buyer processing 12,000 invoices per month on NetSuite with dozens of coding fields per invoice, Vic.ai's VicAnalytics™ module provides invoice-level and vendor-level accuracy reporting, but not the per-field, per-coding-dimension breakdown this requirement specifies. VicAnalytics™ is tiered: Standard Analytics includes 'Total accuracy per vendor' and 'No touch vs touch invoices'; Advanced Analytics adds vendor accuracy performance reports and Autopilot enablement dashboards; Premium Analytics unlocks custom reports and raw data exports (vic.ai/analytics-and-insights; vic.ai/frequently-asked-questions). The platform does track the three invoice states this buyer needs — fully autonomous Autopilot (no touch), human-reviewed (touch), and Autopilot-ineligible — and those are reportable per vendor, which partially satisfies the requirement (vic.ai FAQ). However, no documented mechanism shows a report sliced by individual coding field (e.g., 'what percentage of invoices had location auto-coded vs. manually keyed vs. left blank') across the buyer's dozens of NetSuite dimensions including custom segments. The Premium tier's raw data export capability could theoretically enable this analysis externally, but no out-of-box per-field coding coverage report is documented. The NetSuite integration guide confirms customizable processing insight dashboards with performance data by 'user, region, AI accuracy, and processing time,' but dimension-level coding coverage is not named as a native metric (vic.ai/resources/vic-ai-and-oracle-netsuite).

For a buyer running 12,000 invoices a month across dozens of NetSuite dimensions, the specific reporting requirement is a per-vendor, per-field dashboard that segments invoice outcomes into fully auto-coded, partially coded, and fully manual buckets, trackable over time to measure AI learning model improvement. BILL's documented reporting layer covers payment status, approval workflow completion, and 1099 compliance, none of which address coding coverage analytics. BILL's AI product page claims 95% day-one accuracy on key invoice fields and states that its AI 'automatically codes multi-line items bills,' but all reported metrics are aggregate outputs, not segmented per-vendor or per-field breakdowns. The BILL NetSuite help documentation reveals a manual triage workaround rather than a native analytics report: BILL recommends creating a department, location, or class called 'Unclassified' or 'Uncoded' as the default payables classification, so that a report can be run in NetSuite to isolate bills that need reclassification. This workaround surfaces uncoded bills after the fact but does not expose what percentage were auto-coded versus manually keyed, at what field granularity, or how coverage changes over time across the buyer's custom NetSuite dimensions.