BILL (Bill.com) vs Ramp

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 dimensions per invoice, BILL's documented fallback for fields its AI cannot populate is a silent blank: when Auto Bill Entry cannot read a value, the field is left empty and the bill proceeds into the approval and payment queue without a structured hold, a review flag, or targeted routing to the field's domain owner. BILL's approval workflow routes bills by dollar threshold and vendor identity, not by which specific dimensions are missing, so there is no mechanism to send an uncoded location, class, project, or custom segment to the appropriate budget owner for completion before the record moves forward. …

Limitations: For this buyer's specific requirement, the gap is architectural: BILL has no pre-sync validation layer that identifies which custom dimensions are blank, no field-level exception queue that surfaces those gaps to the right people, and no configurable default-with-flag mechanism per dimension. …

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 running dozens of NetSuite coding fields, Ramp provides three fallback layers when the AI cannot code a field. First, configurable default values act as an automatic fallback: <cite index="2-2,2-3">default values act as a fallback when no rule or user input applies, and they help ensure every transaction is coded and prevent sync errors.</cite> Second, Bill Pay submission policies create a pre-submission gate with field-level identification: <cite index="34-10,34-11">when an employee submits a bill, Ramp checks it against the submission policy; if the bill is missing any required fields, the employee sees an inline error on each missing field with the message 'Required by submiss …

Limitations: Ramp does not document a mechanism for routing a specific uncoded field to the appropriate budget owner or cost center manager for targeted field-level entry; the approval chain handles the whole bill, and approvers with editing enabled can fill missing fields, but this is not per-field domain routing. …

Requirement evaluated: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a portfolio of 8 real estate entities, BILL's multi-entity architecture operates through separate BILL company accounts, one per entity. Each account carries its own approval workflow, its own chart of accounts, and its own user roster, which enforces the entity-scoped data isolation the buyer requires at Stage 5: a budget owner assigned to Entity 3's BILL account cannot see invoices belonging to Entity 1 or Entity 7 because the account boundary is the access boundary. …

Limitations: Each of the 8 entities requires a separately maintained BILL account with its own approval policy configuration, meaning policy changes (new approvers, revised thresholds, updated GL escalation rules) must be replicated manually across all 8 accounts rather than governed from a single policy engine. …

Requirement evaluated: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a portfolio of 8 real estate entities, Ramp's Bill Pay approval workflow builder supports entity-aware routing through a condition-based architecture: administrators build a single global workflow where 'business entity' is available as a branching condition alongside amount thresholds and accounting categories (GL accounts), enabling different approver chains to fire depending on which entity a bill is tagged to. …

Limitations: The approval architecture is a single global workflow with entity-as-a-condition branching rather than 8 isolated per-entity workflow configurations, which means a change to the global workflow logic affects all entities simultaneously. …

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.

This buyer runs NetSuite with dozens of coding fields per invoice including GL account, location, department, class, project, tax fields, and several custom dimensions, all at the line level. BILL does sync custom NetSuite segments into its AP layer: its official NetSuite integration page states it will 'sync your custom segments across bills and transactions to preserve your unique NetSuite setup,' and multiple implementation guides confirm that 'custom NetSuite segments transfer to BILL when properly configured during setup.' Once synced, those segments appear as codeable targets in BILL's bill entry UI, meaning AP staff can manually assign custom segment values rather than being locked ou …

Limitations: For this buyer, the critical gap is at the AI coding layer, not the sync layer: while custom segments flow into BILL's UI and can be coded manually, there is no documented mechanism by which BILL's AI engine autonomously codes those custom dimensions at the line level, meaning the buyer's AP team would still key every …

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 coding dozens of fields per invoice in NetSuite, including GL account, location, department, class, project, tax fields, and several custom dimensions, Ramp's certified SuiteApp integration directly reads the buyer's NetSuite schema and imports all of those fields into the Ramp coding UI, including custom segments. Ramp's official NetSuite overview documentation states explicitly that 'Ramp imports all fields, including custom ones, from NetSuite to ensure comprehensive transaction coding,' and that for segments to be coded in Ramp they must simply be visible on the Credit Card, Bill, and/or Bill Payment Forms in NetSuite. Custom fields are supported at both the header (body) …

Limitations: Custom fields must be active and visible on the relevant NetSuite transaction forms (Credit Card, Bill, Bill Payment) for Ramp to detect and sync them; fields that are inactive or not surfaced on those forms will not appear in Ramp's coding UI. …

Requirement evaluated: Reporting must surface payables aging, outstanding liabilities, and payment history segmented by each of the 8 entities without requiring a manual export or consolidation step, so the central AP team and entity-level stakeholders can see their own view without exposing cross-entity data. This is a downstream output of the entity-scoped routing and dimensional tagging established in req_3 and req_4, and its usefulness degrades proportionally if those upstream requirements are not fully met.

For a real estate portfolio operator running 8 separate entities, BILL's multi-entity model assigns each entity to its own organizational account within a linked structure. The Accountant Console provides a single login with the ability to 'view tasks across all entities from a single screen and switch effortlessly between each one,' per BILL's multi-entity solutions page. Within each entity context, BILL offers native AP aging reports including an AP Aging Summary Report and AP Aging Detail Report, as documented on BILL's aging report learning page, which categorize payables by vendor and days-outstanding for that single organization. …

Limitations: BILL's consolidated cross-entity reporting is confined to operational workflow metrics via the Accountant Console; payables aging, outstanding liabilities, and payment history segmented by all 8 entities in a single permissioned view are not available natively without either context-switching between separate entity ac …

Requirement evaluated: Reporting must surface payables aging, outstanding liabilities, and payment history segmented by each of the 8 entities without requiring a manual export or consolidation step, so the central AP team and entity-level stakeholders can see their own view without exposing cross-entity data. This is a downstream output of the entity-scoped routing and dimensional tagging established in req_3 and req_4, and its usefulness degrades proportionally if those upstream requirements are not fully met.

For a portfolio of 8 real estate entities on NetSuite, Ramp's AP aging and reporting surface is built on top of its multi-entity architecture: bills are tagged to entities during processing, and the AP aging report can then be filtered or downloaded per entity. Specifically, Ramp generates both summary and detailed AP aging reports within Bill Pay, and multi-entity customers can choose to download a report covering all entities or filter by a single entity at download time (Ramp Support: 'Where to view AP Aging Report'). …

Limitations: The AP aging filter is download-time only with no documented evidence of persistent entity-scoped live dashboards for outstanding liabilities and payment history; entity-level stakeholder self-service reporting is gated behind role assignments (Ramp Plus required for custom roles), and the entire entity-segmentation me …

Requirement evaluated: The solution must support a self-service supplier portal where vendors serving multiple of the 8 real estate entities can submit invoices, view payment status, and maintain W-9 or COI documentation in one place, reducing the email volume a 4-person team handles when the same contractor works across residential and commercial properties in the portfolio. Portal adoption friction (whether suppliers actually use it versus falling back to email) must be evaluated explicitly, not assumed.

For a portfolio of 8 real estate entities using separate BILL accounts (one per NetSuite subsidiary/entity), a contractor can connect to all 8 payers through a single BILL Network account. <cite index="64-1,64-3">Once a vendor accepts a network invitation and adds a bank account, they can manage multiple customers who use BILL to pay them all in one account, and send eInvoices to any of those BILL or Bill.com users.</cite> This directly addresses the cross-entity invoice submission and payment visibility requirement: <cite index="68-23,68-24">network vendors get automatic status updates, giving them more visibility into their own cash flow so the AP team spends less time answering questions. …

Limitations: COI document collection, expiration tracking, and vendor-facing insurance certificate management are entirely absent from BILL's product; this buyer must bolt on a dedicated COI platform (such as Jones or Billy) for that requirement. …

Requirement evaluated: The solution must support a self-service supplier portal where vendors serving multiple of the 8 real estate entities can submit invoices, view payment status, and maintain W-9 or COI documentation in one place, reducing the email volume a 4-person team handles when the same contractor works across residential and commercial properties in the portfolio. Portal adoption friction (whether suppliers actually use it versus falling back to email) must be evaluated explicitly, not assumed.

For an 8-entity real estate portfolio where the same contractors span residential and commercial properties, Ramp's Vendor Portal and Vendor Network provide a real but adoption-dependent answer. On the capability side: vendors can submit invoices directly from their portal to any connected Ramp Bill Pay customer, and a single portal account surfaces payments from all Ramp-using payers in one view, meaning a contractor paid by multiple entities sees all activity in one place without separate logins. Payment status visibility by bill is available in-portal, with bill-level statuses ('Invoice received', 'Processing', 'Completed') visible to the vendor. …

Limitations: The absence of any documented portal adoption tracking or email-fallback detection means the 4-person AP team has no visibility into which contractors are actually using the portal versus continuing to email, making the buyer's stated goal of reducing inbound email volume unverifiable and unenforceable. …

Requirement evaluated: Automatic combination of multiple approved invoices to the same vendor into a single payment, with the matching criteria used for combination clearly stated

For a 3-person AP team processing 1,800 invoices per month across two Sage Intacct entities, BILL's payment consolidation works as follows: administrators enable the feature globally under Payables Preferences, then activate it per vendor by checking 'Combine payments' under Payment Processing on each vendor record. Once enabled, BILL automatically combines multiple approved bills to the same vendor into a single check or ACH (ePayment) disbursement. …

Limitations: BILL can combine a maximum of 35 bills per single consolidated payment; vendors with more than 35 open approved invoices in a payment run will require a second payment. Card payments (virtual card, BILL Divvy Card) …

Requirement evaluated: Automatic combination of multiple approved invoices to the same vendor into a single payment, with the matching criteria used for combination clearly stated

For a $120M services company running bi-weekly check runs and monthly ACH batches across 1,800 invoices per month, Ramp's Batch Payments feature in Ramp Bill Pay directly addresses this requirement. Once auto-batching is enabled in Bill Pay settings, Ramp automatically groups approved bills into a single combined payment when they share three criteria: the same vendor, the same payment date, and the same payment details (method, timelines, and source/destination accounts). Auto-batching is on by default for all vendors, with an optional vendor-level filter in settings to include or exclude specific vendors from batching. …

Limitations: Card payments cannot be included in a batch, so any vendor paid via Ramp virtual card or existing card will receive a separate per-bill transaction rather than a consolidated payment. …

Requirement evaluated: The solution must provide segregation of duties controls at the entity level so that within the 4-person AP team, no single user can both approve an invoice and release the corresponding payment for the same entity. This addresses stage 1 (legitimacy) and the audit requirements typical of a multi-entity real estate portfolio, where lender covenants and investor reporting may require demonstrable AP controls per entity.

For an 8-entity real estate portfolio running a 4-person AP team, BILL's role architecture provides a documented foundation for segregation of duties: the Approver role reviews and authorizes bills before payment, while the Payer role can only release payments; <cite index="11-2,11-4">the Approver role reviews bills and vendor credits before authorizing them for payment, and the Payer role is only able to pay bills.</cite> BILL explicitly frames these controls as SOD enforcement: <cite index="13-16">BILL's approval customizations help you maintain separation of duties and reduce potential fraud by allowing you to control which bills need approval, by whom, and when, based on business need.</ …

Limitations: The critical gap for lender covenant and investor audit requirements is that BILL does not enforce a hard system-level constraint preventing a single user from holding both Approver and Payer permissions within the same entity account; the control depends on administrator-level role hygiene. …

Requirement evaluated: The solution must provide segregation of duties controls at the entity level so that within the 4-person AP team, no single user can both approve an invoice and release the corresponding payment for the same entity. This addresses stage 1 (legitimacy) and the audit requirements typical of a multi-entity real estate portfolio, where lender covenants and investor reporting may require demonstrable AP controls per entity.

For a portfolio of 8 real estate entities with a 4-person AP team, Ramp provides a layered segregation of duties architecture across three configurable controls in Bill Pay. First, <cite index="7-1,7-2">a dedicated Separation of Duties toggle in Bill Pay settings prevents a bill creator from approving their own bill; when toggled on, a Ramp account holder cannot approve a bill they created.</cite> Second, and most directly responsive to the buyer's requirement that no single user can both approve and release a payment: <cite index="21-4,21-5,21-6">the Payment Step Approvals feature adds an explicit second gate after bill approval, designed for companies that need clear separation between the …

Limitations: The Payment Release feature (the second gate separating approver from payer) is a Ramp Plus-tier capability: <cite index="21-7">this feature is only available to customers on Ramp Plus,</cite> and custom role creation that enables finer-grained SOD configurations also requires Ramp Plus. …

Requirement evaluated: SOC 2 Type II certification (current, not in-progress)

For a $120M multi-location services company evaluating BILL as its first AP automation layer, SOC 2 Type II is a completed, annually renewed audit rather than a point-in-time snapshot or an in-progress effort. BILL's dedicated security pages confirm that the company undergoes an annual SOC 1 and SOC 2 Type II audit by a leading national CPA firm, covering BILL Accounts Payable, BILL Accounts Receivable, and BILL Spend and Expense. The completed report is available to account administrators and accountants upon request, delivered under a non-disclosure agreement (NDA). …

Limitations: BILL does not publicly name the specific CPA firm conducting the audit (the security page references 'a leading national CPA firm'), and the full report is restricted-use under NDA rather than publicly downloadable. …

Requirement evaluated: SOC 2 Type II certification (current, not in-progress)

For a $120M multi-location services company with two Sage Intacct entities, SOC 2 Type II compliance is a non-negotiable prerequisite before placing financial data in any third-party AP platform. Ramp maintains a completed, current SOC 2 Type 2 audit: its public Trust Center at trust.ramp.com lists the SOC 2 Type 2 report for the period ending October 2025, available for download, alongside a SOC 1 Type 2 report, ISO 27001:2022 certification, and PCI DSS Attestation of Compliance for the same cycle. …

Limitations: The most recent publicly listed report covers the period ending October 2025; as of September 2026 that report is approximately 11 months old, within the standard 12-month validity window, but buyers should confirm the October 2026 renewal cycle report is available before contract execution if timing is tight. …

Requirement evaluated: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For an 8-entity real estate portfolio on NetSuite needing line-item 3-way matching with per-entity tolerance rules, BILL's mechanism fails at multiple stages of the pre-processing journey. BILL does offer 3-way matching between PO, item receipt, and invoice, but its own press release confirms this capability is delivered by syncing item receipt data from QuickBooks Desktop: <cite index="18-2,18-3">BILL customers using QuickBooks Desktop can view purchase orders and match invoices, with PO and receipt details synced from QuickBooks Desktop to automate two-way and three-way matching.</cite> Because this buyer is moving to NetSuite as their ERP, not remaining on QuickBooks Desktop, the document …

Limitations: BILL's 3-way matching receipt gate is architecturally dependent on QuickBooks Desktop item receipt data, making it inapplicable to this buyer's NetSuite environment. …

Requirement evaluated: The solution must enforce 3-way matching (PO plus receipt confirmation plus invoice) at the line-item level for each of the 8 entities, covering stage 2 (PO terms verification) and stage 4 (receipt confirmation) of the pre-processing journey. Configurable tolerance rules per entity and automatic exception routing to the responsible approver when a variance is detected are required; 2-way matching that skips receipt confirmation is not acceptable for a real estate portfolio with vendor work orders and construction invoices.

For a real estate portfolio running on NetSuite, Ramp's 3-way matching operates through its Procurement and Bill Pay modules in combination. <cite index="13-29,13-30">3-way match allows users to match bills in Ramp Bill Pay with purchase orders and item receipts, giving control over AP to ensure payment only for goods received.</cite> The mechanism for Stage 2 (PO terms verification) and Stage 4 (receipt confirmation) …

Limitations: The overbilling tolerance is a single global threshold with no documented per-entity configuration, which means the buyer cannot enforce stricter controls on high-risk commercial construction entities versus residential entities as required. …

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

For a company currently keying invoices manually from email and mail into Sage Intacct, BILL offers two stacked AI extraction layers. The first is the Intelligent Virtual Assistant (IVA): <cite index="10-1">a feature that uses machine learning to extract invoice information from documents in the Inbox.</cite> IVA attempts to pre-populate header-level fields including vendor name, invoice number, invoice date, due date, total amount, and payment terms. …

Limitations: <cite index="10-14">IVA will only make predictions for a bill from the first page of a document</cite>, requiring manual Click and Capture for multi-page invoices, which is a real friction point for subcontractor and facilities invoices that frequently run to multiple pages. …

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

For a multi-location services company forwarding emailed invoices and uploading scanned mail, Ramp Bill Pay's OCR engine automatically ingests documents via an AP forwarding email address or direct drag-and-drop upload, then parses and pre-fills a draft bill within roughly 30 to 60 seconds. At the base OCR tier, the system extracts vendor name, invoice number, due date, payment account details, and line items. The Smart OCR tier (available on Ramp Plus) …

Limitations: Payment terms are not extracted from the invoice as a structured term string (e.g., '2/10 Net 30' with an early-pay discount trigger); instead, Ramp captures the due date via OCR and stores net day terms on the vendor profile, so early-payment discount terms printed on the invoice face would not be parsed into actionab …

Requirement evaluated: Per-vendor duplicate sensitivity configuration for vendors that legitimately reuse invoice numbers (e.g., recurring rent or utility billing)

For a multi-location services company processing ~1,800 invoices per month where rent, utility, and subscription vendors routinely reuse the same invoice number each billing cycle, BILL's duplicate detection operates as a global exact-match check on vendor + invoice number combination. When a bill is entered and the system detects a matching vendor and invoice number, it surfaces a duplicate warning; an approver can then deny the bill with the reason 'Duplicate bill' or the entry can be overridden manually at the point of creation. …

Limitations: No evidence was found of a per-vendor duplicate sensitivity setting, vendor-level exception list, or configurable duplicate check window in BILL's vendor profile or org settings; the recurring bill workaround only applies to bills BILL generates internally, not to externally-arriving invoices from rent or utility vendo …

Requirement evaluated: Clear exception categories: price variance, quantity variance, missing PO, missing receipt, duplicate, vendor mismatch

For a multi-location services company processing 1,800 invoices per month with 55% PO-based spend across two Sage Intacct entities, Ramp addresses several of the six required exception categories but not all with equal depth. Price variance and quantity variance are handled through Ramp's Overbilling Protection module, which operates at the line-item level: admins configure separate thresholds for 'Unexpectedly high unit rates' (a rate percent threshold and a rate amount threshold) …

Limitations: The buyer's requirement calls for six discrete, named exception categories that an AP clerk can triage by type; Ramp's documented model consolidates price, quantity, PO, and vendor signals into a single 'Review recommended' flag at the approval stage, which means clerks must open each flagged bill to investigate the ro …

Requirement evaluated: Integration setup assistance included in implementation; not a separate SOW or additional cost

For a $120M company running 2 Sage Intacct entities, BILL provides a pre-built, native Sage Intacct connector with a documented self-service setup process: the buyer creates a Web Services sync user in Intacct at the top/root level, assigns full module permissions, and configures the two-way sync for vendors, chart of accounts, departments, locations, and bills. …

Limitations: For this buyer's specific scenario, a 2-entity Sage Intacct environment, the evidence consistently indicates that hands-on integration setup assistance beyond self-service documentation is separately scoped and priced rather than bundled into the standard implementation fee; the buyer should require explicit written co …

Requirement evaluated: Integration setup assistance included in implementation; not a separate SOW or additional cost

For a $120M services company running 2 Sage Intacct entities, Ramp's integration setup is designed as a guided, self-serve process rather than a vendor-led professional services engagement. The buyer connects Ramp to Sage Intacct from within the Bill Pay tab by enabling Web Services in Intacct, creating a dedicated Ramp web services user, and entering credentials directly in the Ramp UI. …

Limitations: The buyer cannot rely on a publicly documented commitment that Ramp will provide integration setup assistance as a standard included deliverable: Ramp's own implementation guide explicitly defers 'Ramp's specific involvement or resource commitments during implementation' to individual account team conversations. …

Requirement evaluated: Budget must be checked and enforced at the moment a purchase request is submitted, before any PO is issued or card charge is authorized, using budget data sourced from NetSuite. Requests that would exceed available budget must be blocked or escalated, not merely flagged after approval, so that the current pattern of unchecked spend is structurally prevented.

This distribution company needs budget availability checked against NetSuite data at the moment a purchase request is submitted, before any PO is issued, with hard-stop or mandatory escalation on over-budget requests. BILL's architecture does not support this workflow. BILL operates as an AP automation and card spend platform: its documented budget enforcement lives entirely within BILL Spend & Expense (the Divvy card program), where <cite index="11-1">budget caps by team, department, project, or vendor, card-level limits, per-transaction maximums, and approval workflows that trigger when a purchase would exceed a budget</cite> are enforced at the point of a card swipe. …

Limitations: BILL has no purchase requisition workflow and no mechanism to query NetSuite budget availability at request submission time for PO-bound spend; its budget enforcement is structurally confined to the BILL Divvy Card program, which leaves the buyer's core problem (unchecked PO-request spend) entirely unaddressed. …

Requirement evaluated: Before a requester submits a requisition, the system must display their real-time remaining budget for the relevant dimension and department, calculated against all open commitments, approved purchase orders, and actuals already posted to Sage Intacct. The buyer explicitly called this out: requesters must see their true available balance before they commit, not after.

This buyer needs requesters to see a true available balance, calculated against open commitments, approved POs, and Sage Intacct actuals, before submitting a requisition. Ramp Budgets does provide real-time budget visibility: the module unifies spend data across cards, reimbursements, Bill Pay, and POs into a single budget dashboard, and the budget-based approval workflow feature explicitly documents 'Informed decisions: Display current budget status at the time of approval request.' Budget owners receive live dashboards and can see remaining budget against actuals tracked within Ramp. However, the balance Ramp calculates is sourced entirely from Ramp-native activity. …

Limitations: The buyer's true available balance requirement depends on actuals already posted to Sage Intacct being reflected in the pre-submission display; Ramp's budget balance is calculated only from Ramp-originated spend (cards, Bill Pay, reimbursements, Ramp POs), so any Sage Intacct actuals that did not flow through Ramp will …