Finance Index
Sources and Access Trays in Accounts Payable
Operational segmentation system that routes invoices into the right processing queues and controls visibility by role and organizational boundary.
Sources and Access Trays create operational segmentation within accounts payable workflows, allowing invoices to be routed into specific processing queues based on business unit, department, entity, outsourced intake path, or operating model. This system controls which users can see and process invoices by role, ensuring that work is distributed according to organizational structure rather than flowing into one undifferentiated queue. The segmentation supports scalable AP operations while maintaining proper segregation of duties, permission-scoped search, and audit readiness across multi-entity organizations.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Primary Function | Routes invoices into role-specific processing queues by tray assignment | Reduces manual sorting and ensures proper work ownership |
| Intake Integration | Supports tray-specific email addresses and automated file-based routing | Invoices land in correct queues from the start |
| Permission Model | Role-scoped visibility controls what users can see and process | Maintains segregation of duties across entities |
| Workflow Impact | Approval routing and reporting can vary by tray assignment | Supports different governance models per business unit |
| Scalability | Accommodates organizational changes without separate AP systems | Grows with business complexity while preserving control |
What Sources and Access Trays Cover
Sources and Access Trays establish the operational framework for invoice processing by creating named segments that correspond to how the business is organized. Each tray acts as a processing lane where invoices can be assigned, users can be granted access, and workflow rules can be applied. This segmentation extends across the entire procure-to-pay lifecycle, from initial invoice intake through final payment processing.
The system addresses the challenge faced by multi-entity organizations where invoices arrive through various channels but need to be processed by specific teams with appropriate visibility controls. Rather than forcing all work through a single global queue, trays create structured pathways that mirror real organizational boundaries while maintaining unified AP operations, shared reporting, and consistent approval governance.
Tray Model and Governance
Tray governance establishes the organizational structure that will govern invoice processing. Tray names typically correspond to business units, departments, entities, regions, outsourced service groups, or other operational segments. Each tray becomes a processing lane with its own access controls and workflow behaviors.
The most important design decision is not the tray label itself but the operating boundary it represents. A well-designed tray model should align intake routing, processor ownership, approval conditions, search permissions, and reporting views so AP teams do not have to rebuild segmentation manually at each stage of the workflow.
Intake-Level Routing
Invoice routing begins at the point of entry through source-specific email addresses, vendor submission paths, and automated file processing. When the intake path carries source context, incoming invoices can be assigned to the correct processing queue without manual sorting, helping the right team see the invoice from the moment it enters the system.
For organizations using file-based or outsourced intake, folder-based routing, virtual-drive structures, or CSV batch data can preserve tray assignment as part of the upload context. This allows high-volume processing with proper segmentation maintained throughout, rather than requiring AP teams to assign operating lanes after the invoices are already in the queue.
Role-Based Access Control
Access control operates through role-specific tray assignments that determine which invoices each user can see and process. Different AP roles may need different tray scopes for coding, invoice processing, payment preparation, search, or reporting. This granular control ensures that users see only the work they are responsible for while maintaining the flexibility to assign different tray access across roles.
Assigned approval or task work may still need to remain visible to the person responsible for acting, even when broader processing views are restricted. Payment approvers and users with full visibility roles can require broader data access when their responsibilities include organization-wide oversight.
Processing Queue Segmentation
Daily invoice processing operates within tray-defined boundaries through role-aware work queues and filters. A coder, processor, or payment user should see the invoices relevant to their assigned operating lanes, reducing queue noise and preventing teams from working invoices that belong to another entity or business unit.
Search functionality should respect the same tray boundaries, preventing users from finding invoices outside their assigned scope. Report generation should apply identical filtering, ensuring that operational reporting reflects only the data users are authorized to see. Manual tray filters allow users to narrow their view further when focusing on specific segments within their assigned scope.
Approval Workflow Integration
Approval routing can incorporate tray assignments as workflow conditions, allowing different organizational segments to follow appropriate approval chains. Workflow rules can specify that invoices in certain trays route to designated approvers, supporting varied governance models across business units without requiring separate approval systems.
The system evaluates tray-based conditions alongside other workflow criteria such as amount thresholds, vendor relationships, entity ownership, or document type. This enables routing logic where approval requirements can vary based on both the invoice characteristics and the organizational segment it represents.
Analytics and Reporting Segmentation
Analytics dashboards treat tray segmentation through a two-tier approach that balances organizational oversight with operational boundaries. Summary widgets and aggregated views may display organization-wide data unless manually filtered, supporting executive visibility across all segments. Detailed drill-down views should apply tray restrictions based on user permissions, ensuring that individual invoice data respects operational boundaries.
Tray-specific widgets and filters provide breakdowns that help managers understand workload distribution, bottlenecks, cycle time, and performance across organizational segments. The manual tray filter allows users to focus analytics on their areas of responsibility while preserving the ability to see broader organizational patterns when appropriate.
Automated Source Assignment
File-based intake systems support automated tray assignment through structured folder naming, virtual drive routing, or CSV data mapping. These automated paths can carry source information with the invoice record, ensuring that high-volume processing maintains proper segmentation without manual intervention.
Value lookup tables can translate external system codes into appropriate tray assignments, maintaining consistency across different source systems. This is especially useful when outsourced intake, scanning vendors, or upstream systems use their own entity or department codes that need to map cleanly into AP processing lanes.
Common Misconceptions
Trays are not just financial reporting dimensions
Trays create operational workspaces that affect daily processing, not just reporting categories. They determine which invoices users can see, how approval routing behaves, and where work appears in processing queues.
Approval visibility is not restricted by tray assignments
Approvers can act on any invoice assigned to them regardless of tray. Tray restrictions primarily govern processors and coders, while approvers maintain the flexibility to handle assignments across organizational boundaries.
Analytics widgets do not automatically filter by user tray assignments
Summary charts and aggregated views show organization-wide data unless manually filtered. Only detailed drill-downs automatically apply tray restrictions, requiring users to apply tray filters when they want scoped summary views.
Trays should not be treated as disposable labels
Tray changes can affect visibility, work ownership, reporting, and routing. AP teams should govern tray design carefully, document what each tray represents, and avoid casual changes that could confuse historical reporting or day-to-day queue ownership.
Where This Fits in the P2P Workflow
Sources and Access Trays operate as the foundational organizational layer that affects every subsequent step in the procure-to-pay workflow. Invoice intake systems route documents into appropriate trays based on source channels, ensuring proper segmentation from the moment invoices enter the system. This early routing decision determines which users will see and process each invoice throughout its lifecycle.
Stampli supports this layer through Trays, formerly Sources, which give AP teams a way to align invoice intake, queue ownership, role-based visibility, search, reporting, and approval routing to the way the business is organized. Invoices can carry source context from tray-specific email paths, vendor submission paths, file-based intake, virtual drive routing, or batch data, helping work land in the right operating lane before processors begin reviewing it.
Once the invoice is assigned to a tray, Stampli can use that assignment to shape who can process the invoice, how search and reporting are scoped, and which approval workflow conditions apply. This lets multi-entity, shared-services, or decentralized AP teams keep one connected workflow while still preserving operational boundaries by business unit, entity, department, region, or outsourced intake model.
Frequently Asked Questions
The user's role-specific tray assignments control queue visibility. Coders, processors, payment users, and reporting users may each have different tray scopes depending on their responsibilities. Users with broader oversight roles may see a wider set of invoices than users assigned to a single operating lane.
Invoices can be assigned to trays through tray-specific email addresses, automated file processing with folder-based routing, CSV batch uploads with tray data, vendor submission paths, or manual assignment during processing. The most reliable model is to carry source information into the invoice record at intake rather than waiting for a processor to sort the invoice later.
Yes, approval workflows can include tray as a condition alongside other criteria like amount and vendor. This allows different organizational segments to follow appropriate approval chains while maintaining unified workflow management.
Summary widgets and charts show organization-wide data unless manually filtered using the tray filter. Only detailed drill-downs automatically apply tray restrictions based on user permissions, requiring manual filtering for scoped summary views.
Tray reassignment should be treated as an operational control event, not just a labeling change. AP teams should make sure the reassignment preserves visibility for the responsible processors, keeps approval routing aligned with policy, and leaves a traceable record of why the invoice moved to a different operating lane.
Yes, tray assignments are role-specific. A user who handles coding for one entity and payment preparation for another can have different tray access for each responsibility, seeing different invoice sets depending on the work they are performing.
Search results and reports automatically filter to show only invoices in trays the user can access for their role. Manual tray filters allow further narrowing within the permitted scope, and exports respect the same restrictions.
Payment approvers and users with full visibility roles may need access across trays to support organization-wide payment oversight responsibilities. This broader access should be governed by role design and segregation-of-duties policy rather than treated as default processing access.