Stampli vs BILL vs AvidXchange vs Tipalti vs Medius for AP Automation

This media production company needs AvidInvoice to restrict each production's AP team to viewing only invoices coded to their own Sage Intacct profit center, without creating separate entities. AvidInvoice does carry a role-based permission system: the application is configured with default roles that correlate to specific permissions, and these roles are designed to give the Portal Administrator full control over what business functions should be enabled or restricted from internal users. Separately, the Sage Intacct API integration supports 'next-level data syncing, including invoice images and custom dimensions,' confirming that Intacct profit center dimension values do flow into AvidXchange. Workflow routing can be configured by cost center or GL code to assign invoices to the right approvers, and workflows are built according to the business practices the customer has in place, with as many workflows as needed to accommodate the process. However, the documented permission model controls functional access (which actions a role may perform) rather than record-level data isolation: no source establishes that a production AP team member's invoice queue or search results are filtered at the data layer to only return records coded to their assigned profit center. AvidXchange provides routing and supports approval rules based on amount, roles, and other conditions, but the depth of workflow customization varies significantly by module, and many organizations rely on more straightforward approval logic because advanced workflows are not consistently supported across all modules. The result is a workflow-routing mechanism rather than a dimension-scoped data isolation boundary: invoices are routed to the right team, but cross-production visibility via search or reporting is not demonstrably blocked at the record-retrieval layer.

For a media production company running 9 active productions as profit centers inside one Sage Intacct legal entity, Medius offers role-based and dimension-based controls that partially address the isolation requirement, but the architecture has a material ceiling. On the permission side, Medius roles carry a 'Report and Search access rights' tab that controls which invoices a role can search and view in the system; these rights are scoped per company in Medius's data model. (Source: 'Roles, report and search access rights' on MediusGo Customer Portal — see sourceUrl.) On the coding side, Medius supports dimension-level coding rights: an administrator opens a dimension, enables 'Filter the coding values depending on role settings,' then assigns specific dimension values to each role's 'Coding rights' tab, so a production AP user can only code invoices to their own profit center values. (Source: 'Roles and coding rights' on MediusGo Customer Portal.) Restriction rules can also enforce valid dimension combinations imported from Intacct, preserving ERP coding consistency. However, the isolation boundary in Medius is the 'company' object, not a dimension value inside a single company. Medius's permission model scopes invoice visibility at the company level; there is no documented mechanism by which invoice search and queue visibility is filtered to a subset of invoices within a single company based solely on a profit-center dimension value. The Coding rights feature restricts what a user can code, but does not restrict which invoices they can see, open, or act on in the inbox and search. The buyer's requirement calls for full view/edit/act isolation by production profit center within one legal entity, which is a different and stronger control than coding-value restrictions alone.

This media production company needs each of its 9 active productions, operating as profit centers inside a single Sage Intacct legal entity, to be walled off from one another at the invoice-visibility level while still sharing a consolidated payment run. Stampli's Sage Intacct integration does carry Intacct's dimension framework into its platform: the Sage Intacct integration page confirms support for 'Fields, Custom Fields, Dimensions e.g., Project, Dept, Allocation, etc.' and the system 'embeds itself natively with Intacct and keeps data flowing in both directions,' preserving Intacct's existing chart structure and security model. Stampli also confirms a permission layer on visibility: its Reports page states that 'Stampli uses permission-based controls, ensuring that users only see invoices and data aligned with their specific permissions within the system,' and the invoice management product page documents 'standard and customizable user permissions and roles' used to 'deploy internal controls.' The Sage Intacct page further states that 'entity-level permissions travel automatically from Intacct, so finance admins configure access once and are done,' but this phrasing describes entity-level restrictions flowing from Intacct's multi-entity configuration, not intra-entity dimension-scoped visibility filtering. The buyer's requirement is specifically intra-entity: one legal entity, nine profit centers as Intacct dimensions, each production team restricted to invoices coded to their own profit center dimension value. There is no documented evidence in Stampli's help center or product pages that its permission model supports scoping a user's invoice queue to a specific Intacct dimension value (e.g., profit center = Production 3) within a single entity. The 'entity-level restrictions' mechanism Stampli describes solves the multi-entity case, which the buyer explicitly does not want. Whether Stampli's user-permission system can replicate that restriction at the dimension level, inside a single Intacct entity, is not confirmed.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, the critical requirement is that each production's AP team is restricted at the data layer to only see and act on invoices coded to their production. BILL's documented access control model is role-level, not record-level. BILL offers six pre-defined roles controlling various levels of accessibility, allowing people to participate in payables processes without access to bank or accounting functions; custom roles are available on higher tiers for more granular permission settings. However, there is no documented support for fully custom roles or granular permission-set editing outside the predefined roles, and granularity is role-level only, with no field-level or object-level permission customization documented. On the approval routing side, BILL can route approvals by vendor, location, department, and GL account, and the Sage Intacct integration syncs User Defined Dimensions across bills and transactions to preserve the Intacct setup. However, routing an invoice into a production team member's approval queue is categorically different from preventing that user from browsing, searching, or viewing invoices assigned to other productions. BILL's fixed role model will hit a ceiling if the organization needs granular, object-level permissions. The buyer's requirement, profit-center-scoped record-level visibility enforced at the data layer inside one BILL account, is not a documented capability. BILL's own multi-entity solution page describes isolation as a separate-entity construct, which directly conflicts with this buyer's single-entity, consolidated-payment architecture.

The media production company needs invoice visibility partitioned across 9 productions within a single Sage Intacct legal entity, using a profit center dimension as the isolation boundary, without creating separate books or entities. Tipalti's documented isolation mechanism operates exclusively at the entity level: its Multi-Entity feature grants users visibility scoped to the entities they manage, with the help center confirming that 'users can only view and process invoices for the entities they manage, keeping them focused on their own bill data.' This means meaningful invoice isolation in Tipalti requires configuring each production as a separate Tipalti payer entity — exactly the anti-pattern the buyer explicitly wants to avoid, because separate entities in Tipalti's data model carry separate payment runs, separate funding accounts, and separate workflows. Within a single payer entity, Tipalti's RBAC system controls action-level permissions (View Bills, Process Bills, Submit Payment, 20+ options) but does not restrict which bill records a user can retrieve based on a coded dimension value such as profit center or department. Custom fields for Department, Class, or Location can be added at the bill line level and used as UI filters on the bill list, but these are voluntary filter controls applied by the user — not enforced data-layer restrictions that prevent a Production A AP team member from viewing Production B invoices. The buyer's pre-processing journey through stages 1 through 5 is therefore not protected: any user with the View Bills role in the single entity can see all bills across all 9 productions, with no mechanism to enforce profit-center-scoped record isolation at the data layer.

For a media company running 9 productions as profit centers inside one Sage Intacct legal entity, Medius provides a layered RBAC architecture that enforces intra-entity data isolation without creating separate books. The mechanism operates across three documented layers. First, the role form's 'Coding rights' tab restricts which dimension values a user can access when coding invoices; an administrator enables dimension-level filtering in System Configuration, then assigns each role only the profit center codes belonging to its production, so a production-A AP clerk cannot select or see production-B cost centers. Second, the role form's 'Report and Search access rights' tab specifies the level at which the current role has rights to search invoices in the system, meaning a restricted AP user's invoice search is scoped to their permitted dimension values, while a controller role assigned broader rights can surface invoices across all 9 productions. Third, the connector API documentation confirms that authorization groups can be imported via API and carry company and currency prerequisites, with a dedicated admin configuration page, providing a further organizational scoping construct that can span or isolate routing and visibility by business unit. For centralized payment execution, Medius provides a Pay Approver Role that allows a controller or CFO to review all invoices due for payment on a single screen, create a payment batch, and have it approved and processed securely with full visibility: this is the mechanism that makes a consolidated payment run possible across all 9 productions without requiring separate entity logins or separate books. Queue access itself is role-governed: queue access is granted by going to Administration, Organization, Roles, opening the role, and using the Role's Queues tab to assign specific queues to that role, so production-level AP clerks can be assigned only their production's queue while a central payment admin is assigned all queues. This architecture operates at pre-processing stages 1 through 4 (legitimacy, coding, routing, approval) and extends into payment execution; it does not require a multi-entity structure.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, Stampli's AP Assignments feature is the primary mechanism that delivers production-level isolation with simultaneous cross-unit visibility for central staff. Assignments are configurable operational buckets: each production gets its own assignment, and each assignment can receive invoices automatically via a dedicated email address with pre-coded invoice fields. Crucially, access to assignments is additive: production AP clerks are granted access to exactly one assignment and see only those invoices, while central accounting staff, controllers, and payment administrators can be granted access to all nine assignments simultaneously within the same Stampli instance. As Stampli's AP Assignments documentation states directly, 'Grant AP individuals access to one or more assignments, so they only have access to invoices relevant to them,' and users can be given access to 'any combination of assignments dependent on their role.' This is the role-based cross-unit visibility grant the buyer requires: restricted view for unit-level clerks, unrestricted view for designated central users, all within a single company, single-entity environment with no separate books. The mechanism is reinforced by Stampli's broader permission model, which allows setting permissions 'at both the user and role levels, allowing you to share or withhold information for all or a specified subset of invoices.' The platform explicitly supports centralized and decentralized teams operating simultaneously: 'Trays, automatic routing, dynamic approval workflows, and role-based visibility let shared services teams, business units, and local approvers work in the same system without losing governance.' Because all 9 productions live in one Stampli company connected to one Sage Intacct entity, the central payment administrator has a unified AP queue spanning all assignments, which is what makes a consolidated payment run possible without elevating every clerk to company-wide access.

For a media company running 9 productions as operational units inside one legal entity, Tipalti's Bills module provides a dedicated per-user 'Allowed entities' field that directly enforces the two-tier visibility model the buyer needs. When an administrator adds or edits a user in Administration > User Management, an 'Allowed entities' selector appears: production-level AP clerks are assigned only their specific production entity, while central accounting staff, controllers, and payment administrators are assigned 'All' — giving them simultaneous visibility across every production's invoice queue without requiring a separate login per unit. Tipalti explicitly defines an entity as 'a subsidiary, division, business unit, brand, etc. of your organization,' so the buyer's 9 productions map directly to 9 payer entities inside one Tipalti Hub without creating separate books or separate payment runs. The FAQ confirms the centralized payment model is preserved: 'All bills are in one place and payees are paid across different entities in one place,' so a central payment administrator holding 'All' entity access can execute a single consolidated payment run across all 9 productions.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, the buyer needs row-level data isolation: AP clerks see only their production's invoices, while central controllers and payment admins see across all 9. AvidInvoice does have a role-based permissions system, where a Portal Administrator configures default and custom roles that control what business functions each user can perform, such as coding, approving, voiding, or disputing invoices. However, the documented permission architecture is action-scoped, not record-scoped: it controls what a user can do with invoices that reach their queue, not which invoices from the full company pool appear in their queue at all. AvidXchange's own FAQ describes the platform as one that 'will display all invoices posted to the platform,' indicating a single shared invoice repository per portal, with no documented mechanism to filter the visible invoice list by a profit center, department, or project dimension tied to the logged-in user's profile. The workflow routing engine does direct specific invoices to specific users' queues based on pre-configured rules, but this is approval-routing logic, not a visibility fence: it determines who receives a notification and a work item, not who is prevented from browsing the broader invoice list. No AvidXchange help center article, product page, or fact sheet claim documents a per-production data scope, a 'view all units' elevated role toggle, or any mechanism equivalent to dimension-based row-level security that would let central payment admins see all 9 queues simultaneously while clerks remain restricted to one.

Your scenario requires that production-level AP clerks see only their own production's invoices while central accounting staff, controllers, and payment administrators see all 9 productions simultaneously inside a single BILL account. BILL's permission model is role-scoped, not dimension-scoped. The six predefined roles (Administrator, Accountant, Clerk, Approver, Payer, Auditor) and the available custom roles control what actions a user can perform across the entire account; they do not restrict which invoices a user can see based on a production, location, department, or cost center dimension. The Auditor role, for example, grants view-only access to all account and transaction information with no mechanism to filter that view down to a single production unit. Approval policies can be routed by department or location, but that governs who approves a bill, not which bills each user's queue is scoped to. Because BILL operates as a single shared AP queue for the entire account, there is no documented mechanism to grant a Clerk or Approver visibility into Production A's invoices only while a Controller sees all 9 simultaneously; the buyer's centralized-payment-run architecture requires exactly that bifurcated visibility grant, and BILL's role model does not provide it.

For a media production company running 9 profit centers inside one legal entity on Sage Intacct, Stampli addresses the shared-queue-with-individual-assignment requirement through two complementary features: AP Assignments and Stampli Trays. AP Assignments lets administrators define an unlimited number of named assignment buckets mapped to organizational criteria such as business unit, department, vendor, or any custom field; each assignment can carry its own dedicated email address so invoices arriving for a given production land automatically in that production's pool. Administrators can define an unlimited number of assignments matching the company's structure (region, office, department, or vendor), pre-code any invoice field including custom fields with an assignment, and grant AP individuals access to one or more assignments so they only see invoices relevant to them. Each AP assignment can have its own email address, and invoices emailed to that address are automatically assigned with predefined invoice fields. Within those pools, Stampli Trays provide the shared-queue-with-pick-up mechanic the buyer requires: teams can use Trays to distribute invoice processing evenly; rather than having approvables pile up in individual inboxes, they flow into shared department Trays where available team members can process them as capacity allows, preventing bottlenecks. Administrators can assign individuals, teams, or complete departments to any Tray, and can control which users can view-only, add or change coding, upload supporting documents, or modify the Tray assignment, ensuring appropriate access levels. Billy the Bot reinforces individual ownership within those queues: Billy the Bot learns and streamlines the process of assigning invoice owners in addition to filling out custom fields. Users can only view and take action on invoices that are assigned to them, so that the AP system has proper segregation of duties. This capability sits at Stage 1 (legitimacy and initial routing) of the pre-processing journey and connects forward to Stage 5 (cost allocation) through the predefined field coding attached to each assignment or Tray.

For a media company running 9 productions as profit centers inside one legal entity, AvidXchange's AvidInvoice product routes incoming invoices through a workflow engine configured with pre-determined rules and conditions: invoices are coded, categorized, and assigned to the appropriate workflow before being routed for review and approval. The workflow engine is configured and defaulted based on pre-determined rules and conditions, automatically routing invoices to user queues with notifications, and giving teams visibility into what stage the invoice is in and where it goes next. At the approval stage, AvidXchange supports a role-group model: administrators can create groups or roles so that multiple people are part of one role, allowing any member of that role to action an invoice without requiring the administrator to chase down each individual user. The help center also surfaces a named article titled 'AvidInvoice: Reassign Invoice Workflow' and a separate 'AvidInvoice: Assign an Ad-Hoc Approver' article, confirming that mid-workflow reassignment and ad-hoc approver injection exist as platform features. Permissions within AvidInvoice are role-based and fully customizable: the application ships with default roles that build upon one another, giving a portal administrator full control over what business functions are enabled or restricted from internal users, and those roles are fully customizable. The pre-processing journey covered extends from capture and coding through approval routing and payment, operating as an overlay on top of Sage Intacct. However, the documented architecture is primarily a workflow-and-approval-routing model, not a shared capture-stage pool scoped per production unit with explicit individual invoice assignment during the coding stage.

For a media production company running 9 productions inside one Sage Intacct entity, Tipalti's Bills module does not offer a native shared-queue-with-individual-assignment model at the capture stage. When invoices arrive (via email ingestion, supplier portal, or manual upload), they enter a flat, role-gated bill list visible to all users who hold the View Bills role. There is no production-scoped pool that isolates Production A's invoices into a distinct shared inbox for Production A's AP clerks. Tipalti does support per-bill approver designation: during the coding and review step, an AP processor can select one or more named approvers from the 'Bill approver(s)' field, and once submitted, those approvers receive an email notification and the bill moves to their 'Pending my approval' subtab. Custom fields can be added at the bill header or line level for dimensions such as Department, Class, or Location, which allows filtering the global bill list by production after the fact. Additionally, auto-escalation exists: if an approver does not act within a configured time frame, the bill escalates to their manager. However, the assignment mechanism operates at the approval routing stage, not at queue ingestion. Invoices sit in an unowned state in the shared bill list until an AP processor manually opens, codes, and designates an approver, meaning ownership gaps and duplicate handling risk exist during the pre-coding window. This places Tipalti at the approval-assignment tier of the spectrum, not at the shared-pool-with-explicit-ownership-at-capture tier the buyer requires.

For a media production company running 9 productions inside one legal entity, BILL provides a single organization-level inbox where all captured invoices land after being emailed to a unique company-wide address. Within that inbox, there is documented ability to assign documents to specific team members and apply tags or categories for organization and filtering, and the Clerk role surfaces a personal 'to do list' of documents ready for processing. However, BILL's permission model is role-level only with no field-level or object-level permission customization: the six predefined roles (Administrator, Accountant, Clerk, Approver, Payer, Auditor) are organization-wide, not scoped by production, department, or cost center. This means BILL has no native mechanism to restrict a Production 3 clerk's inbox view to only Production 3 invoices; all clerks with inbox access see the same org-wide pool. The 'assign to team member' action (pre-processing, stage 1 of the journey) exists, but it operates on top of an undifferentiated shared inbox rather than a production-scoped shared pool, which means the visibility isolation component of the requirement is absent.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, Medius delivers shared queue infrastructure through its documented personal queue and group queue architecture. A queue is used to access invoices in the workflow; queues are linked to one or more users via roles and are accessible via the work queue window as either a personal queue or a group queue. Personal queues are tied to a named user, while group queues are general queues that can be shared by several users and can optionally be scoped to one or a few companies. Within a shared group queue, if an invoice is sent to multiple recipients and should not be processed by a given user, clicking 'Not mine' removes it from that user's personal queue while it remains for processing by other recipients, providing a basic shared-pool-with-declination mechanism. For explicit assignment to a named individual, Medius has a manual 'Distribute' step in the workflow where an AP user manually routes an invoice to the correct approver or processor; a dedicated Manual Workflow Task Metrics gadget tracks the rate of invoices stopping at this step. Temporary delegation supports assigning tasks at the User, Role, or User and Role level, and tasks can be assigned to a user directly or to a role assigned to that user. The ceiling, however, is that group queues scoped to specific companies are the primary isolation boundary in Medius, and the buyer's 9 productions are profit centers within one entity rather than separate companies. Routing invoices into production-scoped pools without separating legal entities requires dimension-based routing rule configuration rather than a native queue-boundary primitive, meaning production-level queue segmentation is achievable through workflow rules but is not a native out-of-the-box named feature at the queue definition layer. For tracking individual ownership across these steps, the Task Assignments data source in Reports provides per-user activity detail on invoices handled.

For a media production company running 9 profit centers inside one Sage Intacct entity, Stampli delivers per-production coding rule isolation through three interlocking mechanisms. First, the Sage Intacct integration imports every active dimension: profit center, department, GL account, project, location, and any custom Intacct dimensions, and applies many-to-many dynamic filtering so that when a coder selects a given production's profit center, only the valid GL and dimension combinations for that production appear in the coding screen, preventing cross-production coding bleed. Stampli triggers Intacct Smart Rules and auto-populates project-level defaults on export, meaning Intacct's own validation layer fires on the way out, adding a second enforcement check. Second, Stampli's GL table templates can be scoped per company or per vendor: administrators can create allocation templates specific to a company (allocating across multiple companies) or specific to a vendor (allocating across multiple GL accounts or departments), and templates can be tailored to specific vendors for consistent coding. In this buyer's case, a production-specific template set enforces the correct profit center, department, and dimension defaults every time an invoice is assigned to that production's queue. Third, Billy AI learns per-organization coding patterns and codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from payment and accounting history, and validates vendors and required fields before anyone lifts a finger. The AI's suggestions are bounded by the dynamic filter context, so a production-specific pattern will not bleed into another production's dimension set. This covers the pre-processing journey at stage 5 (cost allocation and coding) and integrates with stage 2 (PO matching) because live PO receipts, work orders, one-invoice-to-many-PO scenarios, and subtotal code imports all reconcile down to the line level without demanding extra work from AP.

For a media production company running 9 profit centers inside a single Sage Intacct entity, AvidXchange's Sage Intacct integration does carry custom dimensions: the official Sage Intacct Marketplace listing authored by AvidXchange confirms 'a robust API integration with next-level data syncing, including invoice images and custom dimensions,' meaning profit center, department, project, location, and user-defined dimensions can all be transmitted to Intacct on posting. The workflow engine supports rule-based coding and routing: rules can be configured so that invoices are coded and routed based on attributes such as department, cost center, GL account, and vendor, and the workflow is 'configured and defaulted based on pre-determined rules and conditions.' What is not specifically documented is a per-production coding ruleset that automatically defaults ALL active Intacct dimensions (profit center + department + GL account + project/location) to the correct production-specific values at the coding stage, scoped independently per production so that one production's coding defaults are enforced for that production's invoices and never applied to another. The evidence establishes that dimension-level data passes through and that workflow rules can incorporate GL and department attributes, but the specific mechanism of 9 independently configured, production-scoped coding ruleset configurations with cross-production isolation has no documented confirmation in AvidXchange's help center or product documentation.

Your scenario involves 9 Sage Intacct profit centers inside a single legal entity, each needing its own isolated coding defaults during invoice processing. Tipalti does carry Intacct dimension fields into bill processing: its Intacct integration syncs GL accounts from Intacct to Tipalti, and custom fields of type 'List' can be mapped to Intacct dimensions including location, department, and project, which then flow back to Intacct on bill sync. At the bill-line level, processors can allocate expenses across department, location, and project per the documented bill-line capture workflow. The 'Bill coding preferences' feature enforces which fields are mandatory for processors or approvers, and a single default expense account can be set at the payer level. However, the documented architecture for per-unit defaults is scoped to the Tipalti 'payer entity' construct — meaning separate Tipalti entities — and per-entity default overrides are configured via Swagger by Tipalti's engineering support team rather than through self-serve admin rules. There is no documented mechanism to configure 9 independent coding rule sets (one per profit center) that automatically pre-populate the correct Intacct profit center, department, GL account, and other active dimensions based on which production an invoice is assigned to, all within a single Tipalti payer account. The coding happens at the bill level by processors selecting values from synced dimension lists, not through production-scoped rule logic that defaults values automatically.

For a media production company running 9 profit centers inside one Sage Intacct entity, Medius addresses per-unit coding through two layered mechanisms. First, the Coding String is configured per company (operational unit) in the administration tool, defining the composition of GL account and all other coding dimensions that together form a coding row; this is where profit center, department, project, location, and any other active Intacct dimensions are mapped. Under System Configuration, the coding string for each company is configured, specifying the composition of the account and other coding dimensions that together form a coding row. Second, Accounting Templates can be scoped to a specific company and to specific suppliers or roles, so that when an invoice arrives for a given production, the correct GL defaults are pre-populated automatically. Each template specifies the company it applies to, and when the Company field on an accounting line is blank, available coding dimension values are determined by the company that owns the template; otherwise, values are determined by the company selected on an accounting line. Restriction Rules add a third enforcement layer: Medius allows restriction rules to define dependencies and conditions in the dimensions tree, ensuring consistency of coding configuration between Medius and the ERP system, with settings typically imported directly from the ERP. Dimension-level filtering by role is also available: each coding dimension can be configured so that the registry is filtered by role, meaning users see only the coding values they need access to, with settings made on the role form. The Sage Intacct integration itself is delivered via a pre-packaged connector. Medius has a pre-packaged integration with Sage Intacct in partnership with Acuity Solutions. The critical gap for this buyer is that Medius's architecture treats each operational unit as a "company" node in its org tree; per-production coding isolation is achievable, but the depth to which that company node maps to all active Sage Intacct dimensions (profit center, custom segments, project, location) depends on what the Acuity-built connector actually surfaces, and there is no published documentation confirming full Intacct dimension fidelity at the coding-string level. The AI coding automation is real: Medius claims matching, coding, and routing handled end-to-end with 95% precision after just two invoices. However, that learned coding is per-supplier and per-company-node; there is no documented mechanism confirming that the AI separately learns and enforces distinct coding defaults for each of the 9 productions when multiple productions share the same supplier.

For a media production company with 9 productions running as profit centers in one Sage Intacct entity, BILL's coding automation operates at stage 1 (invoice capture and GL coding) of the pre-processing journey. The integration syncs Intacct list objects including Departments, Locations, and custom Dimensions at the root level, and bill edits including 'Classifications (Accounts/Departments/Locations/Dimension)' sync back to Intacct. For coding automation, BILL offers two mechanisms: 'Smart Data Entry,' which re-applies the payment terms, description, and coding from the most recent bill for a given vendor; and the Invoice Coding Agent, which creates line-item coding predictions by 'analyzing up to five of the most recent bills for a specific vendor to identify your organization's unique coding habits.' Neither mechanism is a configurable per-production rules engine. Both are vendor-scoped and learn from the organization's aggregate bill history, meaning a vendor that services Production A and Production B will receive predictions drawn from the combined coding history of both, with no mechanism to enforce that Production A's profit center, department, or GL account range cannot bleed into Production B's coding suggestions.

This media production company operates 9 profit centers inside one Sage Intacct legal entity and needs a single payment sweep that posts back with full dimensional fidelity: no separate books, no per-entity payment silos. Stampli's payment mechanism is Stampli Direct Pay, which executes ACH, check, virtual card, or international payments from a single unified workflow and automatically syncs payment data back to the connected ERP. Critically, Stampli operates within the buyer's single-entity Intacct structure rather than requiring separate subsidiary books: the Sage Intacct integration mirrors the full Intacct data model, including custom dimensions, profit centers, Smart Rules, and user-defined fields, and triggers Intacct's own Smart Rules on export exactly as if a user were posting the bill directly inside Intacct. For this buyer's 9 productions, each invoice is coded with its production-level dimensions during the pre-processing journey inside Stampli; when a central AP operator runs the payment batch, Direct Pay sweeps all approved payables from a single queue regardless of which production they belong to, then posts payment receipts back to Intacct carrying every dimension per line. The Sage Intacct Marketplace listing independently confirms that Stampli provides 'full support for the FULL range of native functionality in Sage Intacct,' and Stampli's own integration page states it honors Intacct Smart Rules, auto-populates project defaults on export, and preserves every custom field via dual-document export. One material nuance: Stampli's documented multi-entity payment page describes 'individual bank accounts and direct pay options for each subsidiary,' which is the separate-entity model; however, because the buyer is a single legal entity using profit centers as dimensions rather than Intacct subsidiaries, the correct architecture is dimension-based coding and a single company payment run, which Stampli's Direct Pay and Intacct integration explicitly support without requiring the multi-entity structure.

For a media production company running 9 profit centers inside a single Sage Intacct entity, AvidXchange processes the payment run centrally through AvidPay without requiring a multi-entity or subsidiary structure. The Sage Intacct Marketplace listing confirms AvidXchange offers a robust API integration with next-level data syncing, including invoice images and custom dimensions; and the partner overview sheet corroborates that the API-enabled integration extends well beyond the basics of AP, including support for custom dimensions. AvidXchange's own multi-entity blog explicitly addresses the single-entity, multi-unit scenario: if your organization has one company but many entities or subsidiaries, the solution supports inter-entity processing from a single transaction to various entities/dimensions/subsidiaries. Centralized payment execution is confirmed: AvidXchange is designed to support multi-entity organizations by allowing finance teams to manage payment execution centrally while maintaining entity-level approvals and accounting structures. On loop-back, your company's accounting system remains your system of record, and you'll receive files with all the automated payment information your company needs for reconciliation of your B2B bill payments. However, no source explicitly confirms that the payment posting writes back to Sage Intacct at the line level with full dimensional fidelity (profit center, GL account, and all active Intacct dimensions) per payment line rather than at a header or batch level. A competitor analysis also notes that AvidXchange integrates with many ERPs using batch-style syncing for most environments, although some ERPs support more frequent updates, which introduces uncertainty about whether dimensional data is preserved at the per-line posting level or aggregated.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, Tipalti's payment run operates as follows: approved bills from all productions reside in a single Tipalti payer instance (configured as 'Single entity' in the Intacct integration setup, not multi-entity), and payment batches can be constructed to sweep multiple payees, currencies, and scheduled dates in one execution. Payment batches can be one individual payment or comprise a number of payments submitted together in Tipalti, and the payments in the batch can include multiple payees, currencies, and scheduled dates. Once approved, payments move through the payment cycle before remittance to payees: payment instructions are first submitted to Tipalti, then validated before going through payer and payment provider approval processes. On the Intacct integration side, the 'Payments sync' field can be set to 'Tipalti to Intacct', posting executed payments back to Sage Intacct. GL accounts are mapped between Tipalti and Intacct: AP accounts are linked at the header level, and expense accounts are linked to bill lines in Tipalti. Custom Intacct dimensions (such as profit center or department) can be mapped via the custom field mapping step in the integration wizard, but only List/Record fields from Intacct can be mapped to Tipalti; other Intacct field types are not supported. This restriction means that Sage Intacct dimensions not classified as List or Record field types will not carry through to Tipalti or post back on payment records. Critically, the setup documentation does not explicitly confirm that all active Intacct dimensions (beyond GL account) flow through at line level in the payment postback, which is the full-fidelity requirement this buyer has.

This media production company runs 9 productions as profit centers inside one Sage Intacct legal entity and needs a single payment run that sweeps all approved payables, posts payments back to Intacct with full dimensional fidelity, and requires no multi-entity or subsidiary structure. Medius Pay is positioned as an embedded payment module that initiates payments once invoices are approved and syncs results back to the ERP. Per Medius's payments product page, the module handles 'payments via multiple channels (USA via ACH, Check, Wire, or VCard) in a single consolidated process for each supplier' with 'payments sync automatically to your ERP,' and the Medius AP automation page states that 'payment is built into your AP workflows and fully embedded into the invoice-to-pay process.' However, the Sage Intacct integration is delivered via a third-party partner connector, not a Medius-native connector: Medius's own ERP integration page states 'Medius has a pre-packaged integration with Sage X3 and Intacct in partnership with Acuity Solutions,' a UK-based Sage partner. No public documentation from Medius or Acuity Solutions confirms that this partner connector carries Sage Intacct's full dimensional model (profit center, custom dimensions, location) at the payment posting line level, which is the specific fidelity this buyer requires. The Medius API documentation references 'release payment, preliminary after coding, preliminary after connection' flows and notes that in 'virtual company scenarios where flexibility is needed' the FX API 'might be problematic,' signaling that cross-company or cross-unit payment consolidation carries architectural caveats. On the question of single-entity operation without forced multi-entity structure, Medius's internal documentation uses the concept of 'virtual companies' to organize operational units, which can support consolidated payment runs without separate legal entity books, but the depth of dimensional pass-through from those virtual companies back to Intacct's profit center and custom dimension fields through the Acuity partner connector is not documented in available public sources.

For a media production company running 9 profit centers inside one Sage Intacct entity, BILL operates as a single-org platform that syncs to the root level of a single-entity Intacct instance, which is architecturally compatible with the buyer's requirement to avoid a multi-entity structure. Standard Intacct list objects including Departments, Locations, and Projects carry a 2-way sync, and bills with their classifications (Accounts, Departments, Locations, and Dimensions) sync from BILL into Intacct along with payments. The payment execution model is a bulk-select Pay page where approved bills across the account can be selected and paid in a single session, with the resulting payments syncing back to Intacct as a Cash Disbursement Journal entry. However, three material gaps constrain this buyer: first, BILL's own setup documentation for Intacct integration explicitly advises that required dimensions be disabled ('Ensure that all dimensions are unchecked. Required dimensions may cause sync failure'), which directly conflicts with the buyer's requirement for per-line profit center fidelity on every payment posting; second, BILL does not document a structured payment run with sweep logic that explicitly carries per-line dimensional data (profit center, GL account, additional active dimensions) through the payment journal entry back to Intacct; third, BILL's payment model is a bulk-select interface rather than a configurable scheduled sweep execution. The integration carries dimension data on bill records, but the mechanism for dimension-by-line fidelity on the payment journal posting itself is not established in available documentation.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, Stampli's native API integration syncs Intacct's full dimension schema into the AP coding layer, including standard dimensions (Project, Department, Location), user-defined custom dimensions, Smart Rules, and custom fields, on a five-minute inbound / two-hour outbound cadence with on-demand refresh available. Stampli mirrors Intacct's entities, Smart Rules, and custom fields with five-minute list updates and two-hour sync cycles. User-defined fields and custom documents are preserved through dual-document export, carrying every custom field on both the invoice and the 'paid bill' record. During invoice coding, many-to-many dynamic filtering ensures only valid field combinations, such as entity, location, and vendor, appear during coding. This means a profit center coded in Intacct as a Location, Class, or user-defined dimension surfaces directly as a selectable coding field in Stampli, without any flattening to a generic tag. Stampli enables dynamic filtering of field values based on many-to-many relationships, such as entities, projects, subcontractors, job costs, and others, including custom fields. For line-level fidelity, Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from the company's payment and accounting history. Stampli honors Intacct's Smart Rules by triggering them during export, automatically populates project-level defaults upon export, and creates dual documents to preserve every user-defined field. Entity-level access restrictions travel automatically from Intacct, meaning production-level visibility controls flow directly from the ERP security model rather than requiring a separate setup inside Stampli. Stampli automatically imports and enforces the same entity-level user restrictions configured in Intacct. The integration is a Sage Marketplace-validated connector, built in-house, covering the full data model rather than a standardized subset. Stampli provides full support for the full range of native functionality for more than 70 ERPs.

For a media production company running 9 profit-center-isolated productions inside a single Intacct entity, AvidXchange's Intacct connector uses a documented API-based integration that goes beyond basic AP fields. The Sage Intacct Marketplace listing states the integration provides 'robust API integration with next-level data syncing, including invoice images and custom dimensions,' and the AvidXchange-for-Intacct overview sheet confirms the API connection 'extends well beyond the basics of AP, including support for custom dimensions.' This means the connector can, at minimum, pull Intacct's standard and user-defined dimension lists into AvidXchange's coding interface, making them available for invoice GL coding. However, no publicly available technical documentation from AvidXchange's help center or implementation guides specifies: (a) whether Intacct's profit center dimension type is treated as a first-class, named dimension or is proxied through a generic field mapping, (b) whether GL coding operates at the invoice line level — carrying a distinct full-dimension intersection per distribution row — or is limited to header-level coding, (c) how dimension lists refresh in AvidXchange when new profit center codes are added in Intacct, and (d) whether per-unit coding restrictions can be enforced so that a production-unit AP user's selectable dimension values are scoped to their own profit center. AvidXchange's documented strengths in the Intacct ecosystem center on payment execution via AvidPay and workflow routing, not on deep dimensional coding fidelity. This gap is material for the buyer's requirement because profit centers are the primary isolation dimension; if the connector flattens them to a generic custom-field tag rather than honoring the Intacct profit center data type, per-unit coding rules and per-production GL postings will not be reliably enforced at the line level.

For a media production company running 9 profit centers inside one Sage Intacct entity, BILL's integration operates at the pre-processing stages of GL coding and payment posting (stages 5 and post-approval), syncing bills, payments, vendors, and accounts between the two systems via a Web Services connector. BILL markets explicit support for syncing User Defined Dimensions across bills and transactions: its integration page states it will 'sync your User Defined Dimensions across bills and transactions to preserve your unique Sage Intacct setup,' and a dedicated help article titled 'Sage Intacct sync: custom dimensions' exists in the BILL help center, confirmed alongside a 2021 press release announcing custom dimension support for Intacct customers going live in early 2022. However, the integration requires an admin to manually enable and configure each dimension through Sage Intacct's GL application before it becomes selectable in BILL, meaning new production profit centers are not auto-discovered; they require a configuration step each time. Critically, the BILL Spend and Expense setup documentation explicitly warns that 'required dimensions may cause sync failure,' which is a direct risk for any buyer whose profit center dimension is flagged as required in Intacct. The integration is also an external scheduled-sync connector, not a natively embedded Intacct module, and there is no documentation confirming that profit center (which in Intacct is most commonly implemented as a user-defined GL dimension or a relabeled Location) is treated as a first-class, line-item-level coding field within the AP/AR product specifically rather than just the Spend and Expense product.

For a media production company running 9 productions as profit centers inside one Sage Intacct legal entity, Tipalti connects via a pre-built API integration that bidirectionally syncs GL accounts, vendors, bills, payments, and tax codes with Intacct. Tipalti AP automation integrates with Sage Intacct accounting software via a pre-built API and bi-directionally syncs. At the bill line level, bill lines mirror lines on the invoice and are used to allocate expenses among department, location, project, etc. The integration also supports a custom field mapping layer: admins map existing custom fields between Tipalti and Intacct by selecting from the Intacct fields column and mapping them to a List field type in Tipalti. However, the integration carries a documented hard constraint on field type coverage: only List/Record fields from Intacct can be mapped to Tipalti; other Intacct field types are not supported, and fields mapped automatically in the standard integration are not available for custom mapping. Critically, 'profit center' as a named, first-class Intacct dimension is absent from any documented supported-fields list in Tipalti's help center. The standard sync enumerates GL accounts, payees, departments, and locations, but does not confirm profit centers sync as a distinct Intacct dimension object. Tipalti invoice coding syncs with the Sage Intacct general ledger, and advanced sync logic ensures that Sage data, including entity-specific sub-ledgers, is accurately synced in real time, but this language describes entity/subsidiary structures rather than intra-entity profit center dimensions. There is no documented evidence of automatic dimension refresh when new production profit center codes are added in Intacct; adding entities post-setup requires a support team request.

This media production company runs 9 profit centers inside one Sage Intacct entity, requiring an AP layer that carries every active Intacct dimension through to consolidated posting. Medius does offer a Sage Intacct integration, but the mechanism is a partner-delivered connector: Medius publicly states it has 'a pre-packaged integration with Sage X3 and Intacct in partnership with Acuity Solutions,' and separately lists Sage Intacct alongside NetSuite, SAP, and Microsoft Dynamics as supported ERPs via APIs and standard connectors. The critical fidelity question is what that connector actually syncs. Medius's own fully managed, first-party deep integrations are documented explicitly for Microsoft Dynamics 365, Oracle Fusion, Oracle JDE, Oracle NetSuite, Infor, and SAP; Sage Intacct is not in that tier. It sits in a secondary partner-connector tier. No publicly available documentation from Medius or Acuity Solutions enumerates whether the Intacct connector carries user-defined dimensions (including profit centers as a custom dimension), custom segments, or full dimension fidelity at the line-item level as Sage Intacct's native dimensional model supports. The fact sheet's integration claims describe Medius's ERP layer as one that 'complements ERP systems by automating workflows, controls, and collaboration around the ERP,' and notes that master data is accurately transferred from the ERP to Medius for the first-party connectors; no equivalent depth specification exists for the Intacct partner connector. Medius does support dimensions and custom fields internally (the platform allows searching by dimensions and custom fields across virtual companies), but whether the Intacct connector ingests and posts back every active Intacct dimension, including profit centers and user-defined dimensions, is not evidenced at the level of specificity this buyer requires.

For a media production company running 9 profit centers inside one Sage Intacct entity, BILL's 'Enhanced Approval Policies' feature does allow routing conditions based on department, location, and general ledger account, meaning an invoice coded to Production A can be directed to the approver pool designated for Production A. BILL's product documentation states that enhanced approval policies let you 'route by vendor, location, department, general ledger account, and more' and 'route transaction approvals automatically to designated approvers and approver groups with an expanded set of routing criteria.' However, the critical gap for this buyer is at the permission enforcement layer: BILL's user roles are entity-wide. The six predefined roles (administrator, accountant, clerk, approver, payer, auditor) grant approval authority across the entire BILL organization, not scoped to a dimension or profit center. Custom roles 'may be available for more granular permissions settings, depending on the account's price plan,' but no documented mechanism restricts an individual approver's authority to only invoices coded to their assigned production. The Approver role surfaces all bills assigned to that user on a single Pending Approvals screen, with no system-enforced dimension mask. This means routing can send Production A invoices to Production A's approver, but that same approver, holding an entity-wide approver role, is not systemically blocked from acting on Production B invoices if they are manually reassigned or if policies overlap. The buyer's requirement that 'approvers from one production cannot approve invoices belonging to another' is a hard enforcement requirement that BILL's role architecture cannot satisfy at the system level.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, Medius implements per-production approval scoping through its dimension-based approval rules engine, with no multi-entity structure required. Approval authority in Medius is attached to roles at the coding-dimension value level: each role is granted approval rights on specific coding values (e.g., the cost center or department code corresponding to a given production), and the system enforces those boundaries at the row level during approval. As the MediusGo portal documents, approval rules in MediusGo are set up in different roles based on a coding dimension, and if the approval box is gray, this means that you do not have permission to approve that row. This is the enforcement mechanism: a Production A approver's role carries approval rights only on Production A's coding dimension values; when an invoice coded to Production B reaches the shared AP queue, the Production A approver is systemically blocked at the row level, not just by convention. Beyond standard approval rules, in addition to the ordinary approval rules, which are based on one or more approval-controlling coding dimensions, there is the possibility of administering special approval rules; a special approval rule means that for a certain unique combination of account and coding dimensions, a user or role can be assigned a unique approval right. This allows per-production approval chains to be configured independently, including distinct amount thresholds and multi-level hierarchies per production. Medius offers multiple ways to automate approval flows, including creating authorization groups per vendor, using the reference field on the invoice to identify the first approver and routing according to the default authorization hierarchy, creating unique business logic to ensure invoices route to the correct approver, and applying different approval flows for each invoice line so that invoices can be distributed to multiple approvers simultaneously with each seeing only the cost they are responsible for. The Sage Intacct integration syncs chart-of-accounts and dimension data into Medius's coding string, meaning Sage Intacct profit center codes feed directly into the routing rules without manual re-entry. This operates at pre-processing stage 5 (cost allocation and approval), covering the full approval stage of the pre-processing journey within a single-entity structure that preserves the consolidated payment run.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, AvidXchange's AvidInvoice module uses a departmental workflow model as the primary isolation mechanism: administrators configure separate workflow templates and approver role groups per department (or, in the property management analog, per property), and the platform routes each invoice to the correct queue based on how the invoice is coded. The official AvidXchange workflow blog documents this directly: roles can be defined by each department, which simplifies routing; with departmental setup, a department can only see invoices sent to that department, not others in the company. This covers pre-processing stage 5 (cost allocation routing) and the approval handoff at stage 3 (contract/coding verification). The property management customer story is the closest structural analog to this buyer's scenario: a 100-property operator reports that 'indexing between AvidInvoice and [their ERP] because we have 100 properties — all that indexing goes to each of their workflows and approval processes,' and they execute payment as a single consolidated batch: AvidPay allows the team to 'pay all their invoices in a batch by uploading a single file instead of 20 for each property,' preserving centralized payment runs. The AvidInvoice permissions system provides the administrative foundation: the application is configured with default roles that correlate to specific permissions, designed to give the Portal Administrator full control over what business functions should be enabled or restricted from internal users. Routing rules extend to department, GL account, invoice amount, and vendor: teams can configure approval paths based on business rules such as invoice amount, vendor type, cost center, department, or GL account.

For a media production company with 9 profit centers inside one Sage Intacct entity, Stampli's Predefined Approval Workflows provide the foundational routing mechanism: <cite index='3-4'>Stampli's Predefined Approval Workflows enable AP clerks to create and maintain intelligent workflows that automatically assign invoices to the appropriate approvers based on predefined criteria. The routing key can include department or custom fields drawn directly from the invoice: <cite index='3-6,3-8'>approvers can be assigned based on up to 5 invoice field values such as vendor, company, amount, and department, and controls are enforced at the time of approval assignment. Because Stampli mirrors ERP dimensions at the field level, <cite index='6-4'>Stampli mirrors your chart of accounts, dimensions, entities, and approval logic at the field level, meaning Sage Intacct profit-center or department codes synced from the ERP can serve as the routing key, creating separate approval chains per production. To enforce boundary integrity, the buyer must configure workflows in the fully hardcoded fixed mode: <cite index='25-1,25-2'>with a fixed approval system, assigned approvers cannot be changed unless the workflow is changed; the flexible process alternatively allows approvers to be added or removed with less effort. The ceiling is here: <cite index='16-1'>users can bypass departmental or organizational hierarchies and select any approver under the flexible/dynamic workflow mode, meaning cross-unit approval isolation is a configuration choice, not a system-level constraint enforced regardless of mode. Billy AI suggests approvers based on historical patterns and imported ERP attributes like department and location, but those are suggestions, not mandatory scope restrictions on who is permitted to approve. The approval workflow stage therefore provides dimension-based routing to the correct production approver but does not provide a hard system-enforced permission mask that prevents an approver from one production from being manually added to another production's invoice by AP staff with admin access.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, the buyer needs approval chains that auto-route to the correct production's approvers based on GL dimension coding, with the system enforcing that Production A's approvers cannot act on Production B's invoices. Tipalti's Bills module operates at approval stage 2 of the pre-processing journey (legitimacy and internal authorization). Approver assignment is primarily a per-bill, AP-initiated manual selection: if your process requires an approver or multiple approvers, you can select them from the 'Bill approver(s)' field; if you do not see the required approvers in the dropdown list, you can add them one at a time to the system, for use in this bill and future bills. Tipalti's marketing describes AI routing that 'determines the correct approver based on factors like amount, department, and vendor type,' but no help-center documentation surfaces a configuration interface where an admin defines per-production approver pools keyed to a Sage Intacct class, department, or profit-center dimension value, with system-enforced approval authority restrictions. The structural isolation mechanism documented in Tipalti's architecture is the 'payer entity' model: an entity can be a subsidiary, division, business unit, brand, etc. of your organization; entities can have similar or different AP processes and workflows. However, using separate Tipalti payer entities for each production maps each to a separate Sage Intacct entity and a separate virtual funding account, which is the anti-pattern the buyer explicitly rejected: the Sage Intacct setup requires selecting either 'Single entity' or 'Multi entity.' Bill lines can carry department, location, project, and cost center coding fields: bill lines mirror lines on the invoice and are used to allocate expenses among department, location, project, etc.; someone in your company can create additional custom fields on the bill header or bill line level for collecting details such as Department, Class, or Location; these custom fields display in bill filters and reporting. But there is no documented policy-engine layer that reads those dimension values at routing time and enforces production-scoped approver authority, keeping cross-unit approval access closed at the workflow level the same way it is closed at the visibility level.

For a media production company running 9 productions as profit centers inside one Sage Intacct legal entity, Stampli's dual-lens reporting requirement is addressed through the intersection of three native mechanisms, all operating within a single-company instance. First, AP Assignments create named units (one per production) that scope each AP user's invoice visibility: Stampli explicitly states that you can 'grant AP individuals access to one or more assignments, so they only have access to invoices relevant to them,' and that the system allows you to 'filter and report on invoices by assignment in addition to any invoice field and other criteria.' This means a Production 3 AP coordinator sees only Production 3 invoices in every list view, search result, and report, while a central finance user granted access to all nine assignments sees the full consolidated picture in the same interface. Second, Stampli Reports enforce this scoping through permission-based controls: 'Stampli uses permission-based controls, ensuring that users only see invoices and data aligned with their specific permissions within the system,' and those reports are real-time, covering invoice status, approval state, coding, and lifecycle metrics across the 12 out-of-the-box report types in the Invoice, Invoice Lifecycle, Invoice Status, and Billing Reconciliation categories. Third, the Dashboards layer provides the same permission-governed dual lens at the KPI level: 'Trays route invoices to the right teams automatically, dynamic approval workflows adapt to your approval logic, and role-based visibility keeps access tight,' and dashboards are described as 'contextual, role-specific' so a central finance leader's dashboard aggregates all nine productions while a production-level user sees only their own. The audit trail itself is immutable and captures every coding change, approval action, and status update at the invoice level, satisfying the central oversight model without requiring a rollup across separate entity books.

For a media production company running 9 productions as profit centers inside one Sage Intacct entity, AvidXchange's AvidInvoice module offers a role-based permission architecture where the Portal Administrator controls what each user can see and do: AvidInvoice is configured with default roles that correlate to specific permissions, and these roles are designed to build upon one another to give the Portal Administrator full control over what business functions should be enabled or restricted from internal users. The fact sheet's supporting tier documents a centralized payables view with audit trail: the platform offers a centralized view into the payables process within a single, secure platform, with intelligent reporting and anywhere, anytime access so users always know where approvals and payments stand. AvidXchange's real estate heritage also demonstrates property-level workflow isolation alongside centralized payment execution: properties continue approving invoices and managing budgets while finance teams gain consistency and oversight, and AvidXchange helps finance teams centralize payment execution while maintaining property-level approval workflows. However, no documented mechanism establishes that reporting dashboard views and invoice list views are automatically row-filtered by production unit based on a user's role assignment, meaning the specific dual-lens design (production AP user sees only their unit's invoices in the same grid that central finance sees all 9) is not confirmed as a native out-of-the-box behavior. Third-party reviewers specifically flag this gap: reviewers highlight the audit trail and customizable approval paths, but some cite support delays and reporting limitations.

For this media production company running 9 profit centers inside a single Sage Intacct legal entity, Medius's dual-lens reporting model is built around its internal 'company' object and 'virtual company' rollup construct, not around sub-entity dimensions like cost centers or profit centers. The access control foundation is role-based: Medius AP uses a role-based framework to control what an authenticated user can do within the application; all users are connected to one or more roles, and a role defines what data objects and services users connected to the role can access and in what way. Company membership is the primary scoping lever: for a user to have rights in a company, the user must belong to that company, managed via the Administration Tool under Organisation-Users. Reporting gadgets respect this scoping and support a 'virtual company' construct for rollup views: gadgets include a Company parameter where you can select a virtual company, allowing a central finance user assigned to a virtual company spanning all 9 units to view aggregate invoice status, approval state, and coding in the same dashboards that a production AP user sees filtered to their single unit. The mechanism for dual-lens reporting is therefore: production AP users are assigned to their individual Medius company object; a central finance role is assigned to a virtual company that groups all 9; each user's login context silently filters the same gadget views to their permitted scope. The limitation is that this architecture requires each production to be modeled as a distinct Medius company object, which is a workaround layer on top of a single-entity Sage Intacct configuration, and some gadgets explicitly cannot be used on virtual company level, meaning central finance aggregate reporting would have coverage gaps depending on which gadgets are in scope.

For a media production company running 9 profit centers inside one legal entity on Sage Intacct, this requirement asks for dual-lens AP reporting: central finance sees all invoices across all productions in aggregate (status, approval state, coding), while individual production users see only their own unit's data in the same views. BILL does offer filterable AP reporting and audit trails: its reporting module supports filtering and grouping by department, category, vendor, and user, and its AP controls page documents the ability to 'drill into audit trails for any transaction to see who submitted, edited, and approved it and when.' The AP Insights module extends this further, with administrators able to grant the 'View Payables Insights' permission to any user on a custom role for cross-payables visibility. However, the critical gap for this buyer is the data-isolation half of the dual lens. BILL's access model is built on six predefined platform roles (Administrator, Controller, Accountant, Approver, Clerk, Payer) that apply organization-wide; the documented permission model has no native mechanism for restricting a user's invoice visibility to a specific production unit or department dimension within a single BILL organization. One BILL internal controls article does describe managers being able to 'only view bills that their department is responsible for,' but this is described at the level of general access controls, not as a documented, configurable data-scope filter applied per production unit within the same shared view. There is no evidence of a row-level or dimension-scoped security layer inside BILL AP that would enforce 'Production 3 AP clerk sees only Production 3 invoices' while a central finance user sees all 9 in the same interface, which is the specific mechanism the buyer requires.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, the required dual-lens reporting depends on automatic, login-context-driven row-level invoice scoping: production AP users see only their unit's bills by default, while central finance sees all 9 in the same view. Tipalti's documented access control model does not provide this. User roles in Tipalti govern which tabs and pages appear and which actions are permitted, but within a single payer entity the 'All bills' view surfaces every bill in any status to any user assigned the 'View Bills' role, with no automatic per-production filter. Custom fields (Department, Class, Location) can be created by a Payer Administration user and do surface in bill list filters and reporting, meaning a user can manually filter bills to their production via 'Add filters' on any bills subtab; however, this is a user-applied filter, not an enforced access boundary, and it does not prevent that user from clearing the filter and viewing all productions' invoices. Tipalti's native isolation mechanism is the payer entity model: each entity maps to an Intacct subsidiary, with centralized billing and reporting available across those entities. Because this buyer's 9 productions are profit centers within one legal entity (not separate Intacct subsidiaries), the multi-entity path is architecturally mismatched and was explicitly excluded by the buyer. No documented mechanism exists for automatic row-level invoice visibility scoping by department or profit center within a single Tipalti payer entity.