Attachment_E_Functional_Requirements_-Submittal_F_Worksheets.xlsx

XLSX spreadsheet 492 KB Posted Jul 13, 2026

Attached to: Enterprise Resource Planning (ERP) Software-as-a Service (SaaS) Solution
Solicitation number: RFP 126DT039
Issued by: Denver County, Denver City, Colorado

About this file

Written by GovTribe AI · Jul 16, 2026

This file is a functional requirements worksheet attachment (Submittal F) for the Enterprise Resource Planning (ERP) Software-as-a-Service (SaaS) Solution procurement by the Regional Transportation District (RTD) in Colorado. The RFP seeks a modern, cloud-based ERP solution to replace RTD's existing Oracle E-Business Suite across finance, procurement, and inventory management functions, with secondary consideration for human resources capabilities. The procurement focuses on ERP software platform selection and does not include Systems Integrator services, which will be procured separately in a follow-on RFP. RTD has developed detailed, agency-specific business and functional requirements for finance, procurement, and inventory management, along with representative HR requirements reflective of public transit agency needs. The evaluation will assess vendor proposals based on alignment with documented requirements, long-term strategic fit, overall value proposition, and the maturity, flexibility, and extensibility of the proposed platform to support RTD's goal of implementing a single integrated ERP solution across all administrative business functions.

The functional requirements worksheet serves as a detailed submittal document outlining the specific capabilities, features, and system characteristics that vendor proposals must address. This attachment provides the technical and operational specifications necessary for vendors to demonstrate how their ERP solutions meet RTD's current business needs while supporting the agency's long-term vision for seamless integration across finance, procurement, inventory, and human resources modules. The requirements framework enables vendors to provide comprehensive responses that align with RTD's strategic objectives for a unified ERP platform capable of evolving with the organization's changing business requirements.

View the file

Other files

File	Type	Posted
Enterprise_Resource_Planning_(ERP)_Software-as-a_Service_(SaaS)_Solution.pdf	PDF	Jul 15, 2026
Form_of_the_Contract_-_126DT039.pdf	PDF	Jul 14, 2026
Attachment_G_Cost_Submittal_Forms.xlsx	XLSX spreadsheet	Jul 13, 2026
Attachment_F_Tech._Submittal_F.1_SaaS_Non-Functional_Service_Level_Requirements.docx	DOCX document	Jul 13, 2026
Attachment_D_Submission_Forms_A-G_7.8_Word.pdf	PDF	Jul 13, 2026
Attachment_C_Volume_III_Cost_Proposal_Format.pdf	PDF	Jul 13, 2026
Attachment_B_Volume_I_Technical__Proposal_Structure.pdf	PDF	Jul 13, 2026
SOW_-_Final.pdf	PDF	Jul 8, 2026

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Original_Contents

RTD - ERP Functional and Technical Requirements Worksheet
Requirements Index by Major Topic
Finance
1	General Ledger
2	Accounts Receivable
3	Accounts Payable
4	Budget
5	Purchasing
6	Fixed Financial Assets
7	Grants Mgmt & Project Acct
Human Resources
8	Time and Attendance
9	Leave Management
10	Payroll
11	Employee Recruiting & Talent Acquisition
12	Benefits Administration & Employee Self-Service
13	Position Control and Labor Budgeting
14	Training & Learning Management
15	Performance Management and Employee Relations
16	Incident Management
Asset Management
17	Asset Registry
18	Asset Assignment, Service & Operations
19	Problems, Defects, and Work Requests
20	Asset Condition and Assessment
21	Maintenance Resources and Planned Work Programs
22	Work Execution & Management
23	Component Tracking & Rebuild
24	Warranty Management
25	Operating & Maintenance History Performance Analysis and Costs
26	Budgeting, Asset Planning, & Capital Programming
Materials Management
27	Inventory Item and Catalog Management
28	Warehouse/Storeroom Configuration and Mobile Computing
29	Inventory Issues and Returns
30	Material Receipt and Stocking
31	Material Transfer Between Storage Facilities
32	Material Replenishment
33	Cycle Counting/Physical Inventory
34	Component Serialization and Tracking
35	Inventory Accounting and Valuation
36	Tool Tracking
Technical Requirements
37	General Architecture and Operations
38	Security and Controls
39	Performance and Availability
40	General Reporting and Queries
41	User Interface
42	Network and Data Interfaces/Integration
43	Data Structure and Storage
44	Workflow Management

Instructions

ERROR:#VALUE!	ERP Functional and Technical Requirements Worksheet	CONFIDENTIAL
Requirements Index by Major Topic
1	General Ledger
2	Accounts Receivable
3	Accounts Payable
4	Budgeting
5	Fixed Financial Assets
6	Projects
7	Grants Management and Project Accounting
8	Purchasing
9	Inventory and Storage
10	Inventory Transactions
11	Treasury Management
12	Recruiting and Talent Acquisition
13	Human Resources
14	Benefits Administration
15	Position Control
16	Time and Attendance
17	Leave Management
18	Payroll Processing
19	Performance Management
20	Workforce Development
21	Technical Requirements

Instructions:
-- Requirements are organized by topic in separate tabs. An index of the Topics and Subtopics is shown below.
-- Vendors should not modify any requirements as listed in the tabs.
-- Vendors must provide responses for each requirement in each tab in the following columns:
1. Vendor Response - describes whether the vendor's proposed solution meets the requirement through one of the following responses (non-shaded cells only):
OS	Off the Shelf - meets the requirement out of the box
OSC	Off the Shelf with Configuration - can be configured to meet the requirement without customization or coding changes
PWA	Proposed Work-Around - the intent of the requirement can be met by a proposed work around. Describe in comments column.
CUS	Customization - must be customized or otherwise modified, including coding changes, to meet the requirement
SRPT	Standard Report - can meet the requirement through standard out of the box or configured reports
DNM	Does Not Meet Requirement - does not meet the requirement

2. Customization Estimate, if Applicable - describes the level of effort for customizations
H	High - significant effort to customize - estimate exceeds 80 hours
M	Medium - effort ranges from estimated 40 to 80 hours
L	Low - relatively small effort to customize - estimate 40 hours or less
3. Capability Planned for Future Release - respond "Yes" if this requirement is in the roadmap for a future release of the proposed solution
4. Module(s) Name - designate which software product/module of the proposed solution will meet the requirement
5. Third Party Solution(s) - designate whether the requirement will be met by a third-party product included in the proposed solution (enter the product/module)
6. Comments/Notes - provide any comments or notes necessary to describe, clarify, or explain the vendor response
7

1. GL

ERROR:#VALUE!	Denver RTD ERP Functional & Technical Requirements: 1.0 General Ledger		CONFIDENTIAL
ID	Final Requirement Statement	Priority (HML)	Vendor Response	Customization Estimate, if Applicable	Capability Planned for Future Release	Sub-Module(s) Name (Must match licensed sub-module in cost worksheet A.1 and B.1)	Applicable Third Party Solution(s)	Comments/Notes
1	General Ledger (GL): Provide functionality to enable RTD to record and track accounting information in the general ledger
1.1	General accounting standards and policies - provide the ability to configure financial accounting based on RTD policies and standards
1.1.1	Provide ability to comply with financial accounting and reporting standards in accordance with: GAAP (Generally Accepted Accounting Principles), GASB (Governmental Accounting Standards Board) statements, and CAFR (Comprehensive Annual Financial Reporting) requirements	H
1.1.2	Provide the ability to implement and comply with the Federal Transit Administration's (FTA) Uniform System of Accounts (https://www.transit.dot.gov/ntd/uniform-system-accounts-usoa)	H
1.1.3	Support cash, accrual, and modified accrual basis for accounting	H
1.1.4	Allow multiple accounting functions on different accounting cycles defined by RTD (i.e., Calendar year, State/County fiscal year, Federal fiscal year)	H
1.1.5	Support up to 13 accounting periods per year as defined by RTD (start and end dates)	H
1.1.6	Provide the ability to accommodate dollar amounts in US currency up to $99 Billion and three decimal points ($99,999,999,999.999).	H
1.1.7	Provide audit trails to identify changes made to system parameters and tables that would affect the processing or reprocessing of any financial transaction	H
1.2	Chart of Accounts (COA) - allow RTD to define a unified chart of accounts to accommodate all business units and to enable data collection, financial analysis, performance management, budget planning, and financial and management reporting.
1.2.1	Maintain independent hierarchies in the account structure to support different roll-ups (e.g. financial reporting, budget reporting, project accounting, grant reporting, departmental reporting, and contracts)	H
1.2.2	Allow a configurable/hierarchical account coding structure and organizations structures consisting of a RTD-defined combination of the following segments at a minimum:
1.2.3	Company (multiple)	H
1.2.4	Intercompany	H
1.2.5	Department	H
1.2.6	Interdepartment	H
1.2.7	Fund	H
1.2.8	Account	H
1.2.9	Object	H
1.2.10	Element/Activity (Function)	H
1.2.11	Organizational Unit (Cost Center)	H
1.2.12	Mode	H
1.2.13	Program	H
1.2.14	Grant funding source	H
1.2.15	Future segments	H
1.2.16	Optional Detail (Sub-object, sub-element…)	H
1.2.17	Designate each general ledger account by the following account types:
1.2.18	Summary/Rollup	H
1.2.19	Asset	H
1.2.20	Liability	H
1.2.21	Revenue	H
1.2.22	Expenditure	H
1.2.23	Surplus/Shortage (Equity type)	H
1.2.24	Non-Financial/Statistical	H
1.2.25	Allow the following project coding designations for account transactions at a minimum:
1.2.26	Program	H
1.2.27	Project	H
1.2.28	Line Item	H
1.2.29	Grant/Funding	H
1.2.30	User Defined	H
1.2.31	Allows the following configurable attributes for each account code and segment:
1.2.32	Define maximum segment length and format	H
1.2.33	Designate the account as active or inactive (no transactions allowed)	H
1.2.34	Designate account segments as required or optional	H
1.2.35	Designate as detail or summary level	H
1.2.36	Define an account name for the account	H
1.2.37	Define a long-description for the account (minimum 50 characters)	H
1.2.38	Allow transactions to post only to active accounts within any open period	H
1.2.39	Prevent accounts from being deleted if any activity is posted to them.	H
1.2.40	Allow segments of the Chart of Accounts to be grouped on a user-defined basis into multiple reporting hierarchies	H
1.2.41	Allow users to lookup accounts using one or a combination of account number, key words, a portion of the name, wild card search, and account type.	H
1.2.42	Allow the definition of acceptable account coding combinations (account/element/object) that restrict the use of segments to allow only valid combinations	H
1.2.43	Provide for role-based security to allow/prevent processing of transactions against certain chart of accounts values	M
1.2.44	Automate roll ups at any level of chart of accounts	H
1.2.45	Maintain the history of changes to accounts to enable as-of-date reporting (reports on past data using past account structures)	H
1.2.46	Allow an authorized user to add, delete or change (close, activate or inactivate) accounts and attributes , including automatic notification of appropriate users of the update	H
1.2.47	Enable chart of accounts elements to be set-up, modified or inactivated in advance based on an effective date	L
1.2.48	Provide the ability to associate statistical accounts with financial activity	L
1.2.49	Allow RTD to establish rules, workflows, and/or privileges for account code creation and management	H
1.2.50	Support the establishment of automated and flexible amortization schedules with custom rules for managing prepaid expenses and compliance with accounting standards	H
1.3	Journal Entries and GL Transactions - provide support for recording and validating automated and GL manual transactions.
1.3.1	Allow RTD to define multiple ledgers and sub-ledgers to accommodate various grouping of GL transactions for specific types of transactions, organizational units, or account types	H
1.3.2	Allow manual entry of GL transactions that are immediately validated and posted to the GL	H
1.3.3	Allow the creation of batch journal entries that can be reviewed, edited, and approved prior to posting to the GL	H
1.3.4	Provide the ability to create and save journal templates with pre-defined journal entry details that can be used to fill-in and create new batch journal entries	M
1.3.5	Allow the creation of recurring journals that can be automatically processed based on RTD defined time intervals and effective dates, such as the end of the accounting period.	H
1.3.6	Provide the following header information for journal entries:
1.3.7	Journal identification/batch control number	H
1.3.8	Journal description	H
1.3.9	Approval level required before posting	H
1.3.10	Support unlimited line items (transactions) for journal entries with the following information for each line item, at a minimum:
1.3.11	Account number	H
1.3.12	Amount	H
1.3.13	Date/time to post	H
1.3.14	Sub-ledger or other source of transaction	H
1.3.15	Description	H
1.3.16	Transaction reference number (control number)	H
1.3.17	Memo field - text up to 100 characters	H
1.3.18	Allow users to look up the following information on the screen as a reference during journal entry:
1.3.19	General Ledger accounts, including individual account segments	H
1.3.20	Project accounts	H
1.3.21	Budgetary accounts	H
1.3.22	Automatically validate transactions as entered using the following validations at a minimum:
1.3.23	Valid and active account number	H
1.3.24	Valid account code segment combination	H
1.3.25	Authorized account number for the user security role/department	H
1.3.26	Balanced entries - ensure all entries are in balance	H
1.3.27	Required fields are completed	H
1.3.28	Automatically assign journal entry identification and batch control numbers and prevent duplicate posting for the same journal entry number	H
1.3.29	Provide the ability to create and save journal entries that will automatically be posted based on a future posting date or effective date.	M
1.3.30	Provide the option to automatically validate GL transactions against available budget and provide a warning for insufficient funds. Allow authorized users to override the warning and post the transaction.	M
1.3.31	Route journal entries for review and approval using workflow based on predetermined routing lists, departmental lists and/or type of journal entries. Include rejection abilities, comment abilities and re-routing to originator for correction	H
1.3.32	Provide the capability to import journal entries from external data sources, such as Excel, comma delimited, or other standard Office 365 file formats. Validate imported transactions suing the same validation rules as for entered transactions	H
1.3.33	Allow a user to create a new journal entry by copying from a previously entered journal entry format (copy journal), either by transaction or the entire journal entry.	M
1.3.34	Provide a method for authorized users to reverse journal entries with proper security, workflow approvals, and audit trails	H
1.3.35	Allow the use of recurring journal entries to post accruals and automatically schedule accrual reversals based on RTD defined effective dates	H
1.3.36	System supports accruals offsetting encumbrances to mitigate the double consumption of available budget during month-end close	H
1.3.37	Provide the ability to attach files to journal entries and transactions	M
1.3.38	Provide the option to require attached documentation for specific types of entries	L
1.3.39	Allow users to save journal entries that have not yet been posted or cleared for all validation errors online, and recall the saved entries for further processing	M
1.3.40	Allow user to view impact of pending journal entries without posting	L
1.3.41	Allow journal entries to cross funds, create appropriate due to/due forms, and force self-balancing by fund	H
1.3.42	Provide the ability to store allocation schedules that distribute selected costs (for example indirect or overhead costs). Allocation schedules define percentages and/or business rules for allocating costs across accounts, projects, departments, or cost centers.	M
1.3.43	Automatically prepare journal entries from each allocation schedule based on predetermined rules and posting dates	M
1.3.44	Import allocation schedule(s) from Excel and automatically create journal entry	L
1.3.45	Provide the ability to use statistical accounts as metrics for allocating costs, and allow statistical accounts to be allocated in the same manner as financial accounts	M
1.3.46	Provide audit trails to trace transactions from source documents, original input, other systems, system-generated transactions, and internal assignment transactions, including the user ID, date and time of the transaction.	H
1.3.47	Provide the ability to select and view journal entries and GL transactions by several factors, including one or a combination of:
1.3.48	Date ranges	H
1.3.49	Account number or segment	H
1.3.50	Account types	H
1.3.51	Posting status (for example posted, scheduled, pending approval, etc.)	H
1.3.52	Submitter	H
1.3.53	Key-word description	H
1.3.54	Allow for working simultaneously in multiple fiscal and budget years (i.e., process transactions for two or more years at one time)	H
1.3.55	Provide the ability to query and view journal entries, ledgers and sub-ledgers, accounts, and all transactions based on user defined criteria, including date range, fund, account, project, cost center (department), or other account segment	H
1.3.56	Provide the option to utilize encumbrance accounting for pre-encumbrance (requisitions) and encumbrance (purchases), and automatically liquidate encumbrances when associated expenditure transactions are posted.	H
1.3.57	Provide streamlined drilldown capability within each GL transaction	H
1.4	Cost Accounting - provide ability to record, analyze, and report RTD Costs
1.4.1	System allows each department to allocate direct and indirect costs differently (with approval) and maintains historical and effective date changes	H
1.4.2	Produce various allocation schedules prior to the financial closing for the period.	H
1.4.3	System allows changing allocation schedule at any time (with approval) during year	H
1.4.4	Automatically prepares a journal entry from each allocation schedule.	H
1.4.5	Import allocation schedule(s) from Excel or other sources and automatically create journal entry	H
1.4.6	System creates reversing entry for changes to an allocation schedule	H
1.4.7	System stores workload statistics or other metrics as method of distributing costs	H
1.4.8	System can selectively apply overhead cost based on chart of account segment e.g. overhead cost applied to interdepartmental transaction; overhead cost applied to operational units but not grant funded activities, based on user defined criteria	H
1.4.9	Ability to perform cross department charges based on internal allocation rules, as defined by RTD.	H
1.4.10	Ability to report on all cost allocations, with both source and destination allocation details.	H
1.5	Period-End processing - provide support to close accounting periods and open new periods
1.5.1	Allow RTD to define period closings, such as month (or accounting period), quarter, and annual (fiscal or calendar)	H
1.5.2	Provide ability to provide year-end closing procedures that close-out revenues and expenditures/expenses, and carry forward the appropriate balances	H
1.5.3	Allow closing entries to prior period until period is closed	H
1.5.4	Provide ability for authorized users to reopen closed periods	H
1.5.5	Provide ability to roll encumbrances and remaining budget associated with encumbrances to next fiscal year by:
1.5.6	All encumbrances	H
1.5.7	Individual encumbrances	H
1.5.8	Selection based upon chart of account segement	H
1.5.9	Groups of encumbrances	H
1.5.10	Provide the ability to allow a period soft close that allows posting of subsequent transactions (for example, interest allocations, balancing activity, etc.)	M
1.5.11	Allow transactions for the next fiscal year to be entered before the old fiscal year's preliminary closing, with the transactions held in suspense until the new fiscal year is opened	H
1.5.12	Allow for the start of processing against any open period in the new fiscal year prior to the close of last fiscal year.	H
1.5.13	Restrict retroactive transactions only to open periods	H
1.5.14	Allow prior period adjusting transactions in current period	H
1.5.15	Provide ability to archive “prior year history” at close of year	H
1.5.16	Provide ability to help finance and accounting teams streamline and automate the financial close process by utilizing close task managers, workflows, dashboards, and automated tools	H
1.5.17	Provide the ability to automatically reconcile accounts, based on user defined parameters via the configuration of reconciliation process flows, status indicators, and established workflows (e.g., not all accounts or only low-risk accounts)	H
1.5.18	Automate the process of matching transactions with bank statements, credit card statements, and other financial sources	H
1.5.19	Provide centralized workflow, with notifications and trigger reminders, for all financial closing activities	H
1.5.20	Provide tracking and reporting capabilities related to the financial close process	H
1.6	Financial Reporting - support all internal and external financial reporting requirements
1.6.1	Provide a financial system report writer that allows RTD to design and develop financial report formats to save and run on demand	H
1.6.2	Provide the following standard financial reports based on GAAP, at a minimum:
1.6.3	Detailed variance reports including encumbrance detail (PO, vendor, current year encumbrance balance, current year expense & accrual activity)	H
1.6.4	Trial balance by fund, project, and cost center	H
1.6.5	Balance sheet and statement of net position	H
1.6.6	Statement of revenue and expenses (income statement)	H
1.6.7	Statement of cash flow	H
1.6.8	Detailed activity reports by fund, account, cost center, or project	H
1.6.9	All CAFR financial schedules	H
1.6.10	Provide the ability to configure and run reports based on the following criteria:
1.6.11	Month-to-date, month-end, quarterly, year-to-date, annual or other user-defined date range	H
1.6.12	Summary or detail levels for accounts and transactions	H
1.6.13	By fund, project, cost center (department), or consolidated (all)	H
1.6.14	Detailed reports including encumbrance detail (PO, vendor, current year encumbrance balance, current year expense & accrual activity)	H
1.6.15	By selecting specific account code or account code segment ranges	H
1.6.16	Generate reports through on-screen inquiry, hard-copy printout, or a print-file for later printing	H
1.6.17	Produce interim financial statements at month end for all types of funds (example: enterprise, general, special revenue, etc.)	H
1.6.18	Produce reports for any fiscal period, open or closed, e.g. month, quarter, year.	H
1.6.19	Provide the option to include current to prior year comparisons in reports, to include % changes	H
1.6.20	Produce line item and fund expense reports that compare current actual and year-to-date actual to current budget and year-to-date budget amounts.	H
1.6.21	Produce an account analysis report showing all transactions for a given account by any user-defined period (e.g., month, year-to-date, quarter, multiple fiscal years)	H
1.6.22	Report on multi-year projects and report for different timeframes, such as fiscal year, the Federal fiscal year and/or life to date for a specific project or projects based on user-defined parameters	H
1.6.23	Provide drill down capabilities to access detail from any field to the originating transaction or source document within the general ledger	M
1.6.24	Provide retrieval of summarized historical data to view online and drill down to the lowest level of transactional detail	H
1.6.25	Allow for departments to view revenue and expenditure activity against their accounts at any time	M
1.6.26	Provide ability to run historical financial reporting across fiscal and calendar years with a minimum of current and two previous years simultaneously	M
1.6.27	Provide ability for users to design queries and extract files for their specific requirements	M
1.6.28	Provide an option to list all detailed accounts that are combined into each line of the financial reports for verification of accounting accuracy	M
1.6.29	Provide ability to search chart of accounts for inactive accounts with no history (by user defined time period)	L
1.6.30	Provide the ability to create and display dashboards with account balances, transaction counts, encumbrance details, statistical accounts, budget variances, and performance indicators relating to each	H
1.6.31	Produce a detailed transaction register or audit report showing all batch summary and individual postings made to the ledger for a user-defined period	H
1.6.32	Produce an adjustments journal for a user-defined period	M
1.6.33	Support TIN matching integration with W9 submission	H
1.6.34	Provide the ability to export reports to Excel, comma delimited, or other Microsoft Office formats	H
1.6.35	Provide for on-line inquiry to account balances, available budget and to detail posted transactions	H
1.6.36	Ability to compile GL expense data and perform reporting for conformance with NTD F30 reporting standards and needs (Mode, Activity, etc.)	H
1.6.37	Provides comprehensize reporting capabilities to monitor and reconcile prepaid and amortization accounts (e.g., schedule reports, summry reports, audit trails, etc.)	H
1.6.38	Ability to pull a centralized list of current function codes that gets designated as recurring/non-recurring to avoid discrepancies with reporting	H
1.7	Cash Management and Bank Reconciliation - provide support for managing cash/checking accounts and reconciliation of accounts with the bank
1.7.1	Provide ability to support multiple cash accounts	H
1.7.2	Provide the ability to capture the type of payment (cash, check, ACH, wire, credit card) for cash account transactions	M
1.7.3	Provide ability to import a list of cleared checks from the bank for each account	H
1.7.4	Provide ability to manually indicate that a check has been cashed and make corrections with an audit trail	H
1.7.5	Allow for cancelling checks by batch or check number range	M
1.7.6	Provide drill-down capabilities to see if a check has been issued/cleared for a specified account and originating transaction documentation	H
1.7.7	Support tracking of manual check issues, voids and replacements and the original dollar amount of the voided check	H
1.7.8	Track the resolution of adjustments that need to be made as a result of an error identified within bank reconciliation	M
1.7.9	Provide ability to enter check adjustments through a journal entry with proper authorization	H
1.7.10	Allow for accounting for missing checks due to issues with printing	H
1.7.11	Provide the ability to query unclaimed/stale dated checks and resolve based on RTD defined expiration periods	M
1.7.12	Support import of paid check image file from bank which will update the check register sub-system	H
1.7.13	Track check status including outstanding, cleared, stale-dated, replaced, returned and voided	H
1.7.14	Support import/download of bank item activity (BAI transmission) from financial institution	H
1.7.15	Support performing of clearing transactions to match imported bank items to journal entries	H
1.7.16	Support reconciliation of deposits with cash receipt details that tie back to a deposit slip with a breakdown by account	H
1.7.17	Provide ability to view a check register for multiple accounts which contains a cumulative list of all checks issued, and can be filtered by account, check number range, date range, and check status (pending, cleared, voided, cancelled, etc.)	H
1.7.18	Generate a report of incoming/outgoing bank items that captures all bank activity	H
1.7.19	Systems automates the process of reconciling checks processed thru the system against bank records of check processes	H
1.7.20	Generate a bank reconciliation report, listing GL cash balances, payments and deposits for a user-defined time period, and outstanding payments (e.g., checks) and deposits for each bank account	H
1.7.21	Provide the ability to capture credit card receipts through interface with credit card processing service providers	H
1.8	GL Interfaces
1.8.1	General ledger natively integrated will all other modules within ERP system	H
1.8.2	Automatically import payroll transactions from ERP into a payroll ledger (dollars and hours)	H
1.8.3	Provide the ability to import Journal Entry transactions from an Excel spreadsheet	H
1.8.4	Provide the option to automatically post imported ledgers transactions or hold the ledger for review prior to posting	M

2. AR

ERROR:#VALUE!	Denver RTD ERP Functional & Technical Requirements: 2.0 Accounts Receivable		CONFIDENTIAL
ID	Final Requirement Statement	Priority (HML)	Vendor Response	Customization Estimate, if Applicable	Capability Planned for Future Release	Sub-Module(s) Name (Must match licensed sub-module in cost worksheet A.1 and B.1)	Applicable Third Party Solution(s)	Comments/Notes
2	Accounts Receivable (AR): Provide full Accounts Receivable functionality and serve as the system of record for all RTD receivables and fully integrate with GL
2.1	Customer Management - provide a customer master file to contain information for supporting accounts receivable
2.1.1	Identify customers using a unique customer ID with the option to have the system automatically assign the ID	H
2.1.2	Allow customer name, alias, DBA, and other identification information	H
2.1.3	Allow RTD to define funding sources as customers for the purpose of executing funding drawdowns from funding commitments	H
2.1.4	Designate a customer type classification using a standard RTD list, configurable by RTD	H
2.1.5	Provide multiple invoicing addresses per customer, with one designated as the default address	H
2.1.6	Provide multiple "ship to" addresses per customer with one designated as the default address	H
2.1.7	Provide information for multiple customer contacts (name, phone, email, fax, etc.) with one designated as the primary contact	H
2.1.8	Provide default payment terms for the customer	H
2.1.9	Designate a customer status as active, inactive (no transactions allowed), or suspended (no further transactions except payments)	H
2.1.10	Define credit limits for a customer, for an individual invoice and in total	M
2.1.11	Accumulate purchase and payment history for customers and allow user to view on-demand	H
2.1.12	Accumulate payment performance history (on-time versus late payments)	M
2.1.13	Provide the ability to designate customer types (e.g., fare media retailer)	H
2.1.14	Allow users to query customers by customer number, name, address, phone, A.K.A names (with revision history) or primary contact	H
2.1.15	Allow customer to be linked to a parent organization	H
2.1.16	Provide a warning message for what appears to be a duplicate customer	M
2.1.17	Designate a primary method of contact, such as email, phone, text, or paper	M
2.1.18	Support multiple attachments of various file types to a customer record (such as images, files, documents, etc.)	H
2.2	Products and Order Management for RTD defined standard products, offerings, and other revenue sources for which RTD will accept payments, including commitments from funding sources.
2.2.1	Support shippable and non-shippable product setup	H
2.2.2	Provide Item Master functionality for item setup, updates, and assignment across organizations	H
2.2.3	Allow setup and modification of item templates	H
2.2.4	Maintain attributes from the Item Master for use in item templates	H
2.2.5	Support defining default expense accounts at the item level	H
2.2.6	Support returns acceptance and recording of inspection results for items	H
2.2.7	Allow management of miscellaneous receipts for product items, including accounting and zero-cost receipt handling	H
2.2.8	Support maintenance of warehouse inventory for new and existing products and item setup	H
2.2.9	Track quantity available, reserved inventory, tracking numbers, and serial numbers	H
2.2.10	Support setup and maintenance of order types, including those used manually in AR	H
2.2.11	Support default accounts based on transaction type (e.g., billed vs. unbilled)	H
2.2.12	Define and manage invoicing and accounting rules for revenue recognition and distribution	H
2.2.13	Support line-level credit checks on orders	H
2.2.14	Maintain numbering sequences for orders (e.g., MMYY, serial number format)	H
2.2.15	Support creation and maintenance of sales orders, including “ship only” and “non-ship” order lines	H
2.2.16	Allow users to review, copy, and modify orders, including copied orders from prior months	H
2.2.17	Support sales order inquiry and order status queries (e.g., not shipped, staged, shipped)	H
2.2.18	Provide order line types such as Future, Standard, Ship Only, and Returns	H
2.2.19	Allow addition of new order lines or deletion/cancellation of existing ones	H
2.2.20	Support custom descriptive flex fields (DFFs) for order lines (e.g., MMYY, Extract ID, Serial Range, Date)	H
2.2.21	Allow selection of quantity and inventory restriction by criteria (e.g., organization query)	H
2.2.22	Support rollback functionality to revert orders to prior stages	H
2.2.23	Provide error notification and stuck line management tools for clearing failed lines	H
2.2.24	Support mass changes on sales orders (e.g., add, reduce, delete, zero-out)	H
2.2.25	Support setup and processing of standing orders (e.g., monthly passes, consignment orders)	H
2.2.26	Allow copying prior month’s standing orders and modification of quantities or details	H
2.2.27	Support staging table processing for standing orders	H
2.2.28	Allow assignment of serial numbers to standing orders	H
2.2.29	Provide alerts and notifications for successful file transfer or failed processing	H
2.2.30	Allow rollback and resubmission for standing order processing errors	H
2.2.31	Support standing order reporting and consignment tracking	H
2.2.32	Support pick release, schedule release, trip stop, and ship confirm processes	H
2.2.33	Allow manual and automatic ship confirmations, including partial shipments and backorders	H
2.2.34	Provide ability to handle shipping exceptions, holds, and exception notifications	H
2.2.35	Support multi-warehouse shipping, warehouse-to-warehouse transfers, and multiple locations	H
2.2.36	Allow decimal quantity shipping when applicable	H
2.2.37	Generate packing lists, shipment notifications, and freight cost tracking	H
2.2.38	Maintain shipping terms, carrier data, and shipment documentation	H
2.2.39	Support purge and completion of ship confirm exceptions	H
2.2.40	Maintain price lists for all products	H
2.2.41	Allow price adjustments directly on price lists or ad hoc during order entry	H
2.2.42	Support price list copying, item additions, and end-dating or deletion of items	H
2.2.43	Manage qualifiers and modifiers used in price calculations	H
2.2.44	Support blanket sales agreements (BSAs) and related price schedules	H
2.2.45	Support creation of Return Material Authorizations (RMAs) tied to the original price, original order, or invoice	H
2.2.46	Support RMA reason codes, reference fields, and free-form reference entry	H
2.2.47	Allow RMA processing at multiple locations with inspection and issue confirmation	H
2.2.48	Support RMA updates to serial numbers and apply to customer account or invoice as required	H
2.2.49	Support RMA generation without original reference when required	H
2.2.50	Transfer completed sales orders to Accounts Receivable (AR) for invoicing	H
2.2.51	Provide transfer to AR exception reporting, listing stuck orders, customer numbers, failed lines, and reasons	H
2.2.52	Maintain invoice types, effective dates, and invoicing criteria for sales orders	H
2.2.53	Support release of individual sales orders for invoicing	H
2.2.54	Generate invoice and order acknowledgment documents for customers	H
2.2.55	Generate and transmit order acknowledgments and packing lists	H
2.2.56	Allow reprinting or resending acknowledgments as needed	H
2.2.57	Support customer acceptance acknowledgment for sales orders	H
2.2.58	Support release of sales orders automatically for invoicing after hold removal	H
2.2.59	Provide tools to release orders on credit or shipping hold	H
2.2.60	Maintain pending and backorder tracking for unfulfilled items	H
2.2.61	Generate error notifications and exception reports for line, shipment, or AR transfer failures	H
2.2.62	Provide stuck line management tools to identify and resolve failed transactions quickly	H
2.3	Customer Sales and Receivables - record sales and create receivables for funds due to RTD
2.3.1	Allow RTD to record sales from a list of standard products and services with pre-determined standard prices and default account numbers	H
2.3.2	Allow RTD to create a receivable for drawdown of a specific funding amount committed from a funding source	H
2.3.3	Provide the option to record cash sales and automatically apply cash receipts to the correct accounts	H
2.3.4	Allow creation of a receivable for any ad hoc or one-time source of revenue, such as a reimbursement, charter service sale, donation, etc.	H
2.3.5	Automatically calculate and apply sales tax based on products, if applicable with default set to “none”	M
2.3.6	Provide the option to create or suppress invoices and/or monthly statements for a non-cash sale or customer	H
2.3.7	Allow RTD to create receivable types to categorize receivables into the following at a minimum:
2.3.8	Fees for service	M
2.3.9	Fees for use of Vanpool	M
2.3.10	Funding drawdown	M
2.3.11	Freight/Postage	M
2.3.12	Penalties and Interest	M
2.3.13	Maintain sales history by product and customer for both cash and non-cash sales with multiple data fields included	H
2.3.14	Provide the ability to add notes or text description for a sales transaction	M
2.3.15	Provide the ability to attach documents, images, or other files to a sales transaction	H
2.3.16	Provide the ability to set up recurring sales, funding commitments, or other receivables that repeat on a user-defined time interval (for example monthly)	H
2.3.17	Provide the ability to designate expenses eligible for reimbursement (FTA, State, Local) by agency and prepare invoices for drawdown	H
2.3.18	Provide abillity to charge internal departments for goods and services	H
2.4	Invoicing and Statements - create and distribute receivable invoices and statements to customers and revenue sources
2.4.1	Allow RTD to create invoices from sales, funding drawdowns, or any receivable	H
2.4.2	Allow RTD to prepare invoice detail from a list of standard products and services with pre-determined standard prices and default account numbers, and modify as necessary for the invoice	H
2.4.3	Provide the ability to enter and create ad hoc invoices for any source of revenue or funds	H
2.4.4	Provide the capability to enter sales items not included on the standard list	H
2.4.5	Allow RTD to add freight, postage, or other miscellaneous charges with account numbers	H
2.4.6	Allow RTD to modify default account numbers or add new account numbers	H
2.4.7	Automatically retrieve default customer information - invoicing address, payment terms, etc. and edit the information as necessary for the invoice	H
2.4.8	Automatically default the invoice date to the current date, but allow users to override the default	M
2.4.9	Provide an option to automatically create an invoice number	M
2.4.10	Provide the capability to create an invoice template that can be copied to create new invoices	H
2.4.11	Provide ability to modidy default templates and customize for different invoice types	H
2.4.12	Automatically calculate and apply appropriate taxes if sales tax applies	H
2.4.13	Allow the option to import invoices from a spreadsheet or external file, and perform all edit checks and provide a method to suspend invalid transactions until corrected	H
2.4.14	Provide the option to invoice in advance or in arrears	H
2.4.15	Provide the capability to define recurring invoices	M
2.4.16	Allow RTD to define unlimited invoice transaction types (e.g. sales, deposits, debit/credit memos, warranty claims, etc.)	M
2.4.17	Allow RTD to invoice full or partial amounts for receivables	H
2.4.18	Provide on-line inquiry of invoice transaction detail and status	H
2.4.19	Maintain current outstanding balances by customer location	H
2.4.20	Allow full on-line inquiry of customer invoice lines and payment detail	H
2.4.21	Provide a method of recording returns or cancellation of sales	H
2.4.22	Allow RTD to design multiple custom invoice formats	M
2.4.23	Provide the capability to select and distribute invoices to customers using a combination of criteria, including receivable date range, type, or customer ID, invoice number or range of invoice numbers.	H
2.4.24	Provide the option to distribute invoices to customers using email, fax, or printed paper	H
2.4.25	Allow for coding of revenue by fund, source, type, and all other elements of the RTD chart of accounts elements	H
2.4.26	Define the invoice due date based on default customer payment terms	H
2.4.27	Allow an authorized user to override the payment term and specify the day payment is due	H
2.4.28	Provide option to insert text comments on invoices	M
2.4.29	Print payment terms on an invoice	H
2.4.30	Provide the ability to process customer service credits to accounts and itemize on the invoice	H
2.4.31	Provide the option to create a customer statement and distribute with invoice amount, applied credit balance and any remaining amount due or in credit on the invoice	M
2.4.32	Provde the ability to attach files and images to multiple levels of the invoice or statement (e.g., header, batch, line item, etc.)	H
2.4.33	Allow RTD to define invoice types	H
2.4.34	Provide the option to generate consolidated invoices for customers with multiple receivables and include multiple lines with different revenue accounts	M
2.4.35	Support credit balances on customer accounts	H
2.4.36	Allow prepayments that create a credit balance	H
2.4.37	Apply credit balances to future invoices	H
2.4.38	Integrate with payables to cut one-time checks for credit balances	M
2.5	Receivable Payments - process all receipts and cash and apply to appropriate customer, invoice, and account
2.5.1	Allow users to search for receivables by customer (or funding source) and/or invoice number, dollar amount, dollar range, date range, receipt number and enter payments against the receivable.	H
2.5.2	Display all open customer invoices during payment posting and allow the user to view all the invoice information to determine if the receipt is being applied to the proper transaction when applying a receipt to an invoice	H
2.5.3	Apply cash receipts either manually or automatically to open line items, open invoices or active accounts and provide functionality to control the sequence in which a payment is applied to multiple lines	M
2.5.4	Receive and apply deposits not against an invoice and credit appropriate revenue accounts	H
2.5.5	Allow payments to be applied to multiple receivable invoices	H
2.5.6	Allow partial payments for a receivable invoice	H
2.5.7	Automatically update invoice balance due after processing payments and close invoices that are fully paid	H
2.5.8	Record all types of payments against receivables, including but not limited to:
2.5.9	Cash	H
2.5.10	Checks	H
2.5.11	Money orders	H
2.5.12	Cashier's checks	H
2.5.13	Electronic payments/ACH transactions	H
2.5.14	Wire transfers	H
2.5.15	Credit cards	H
2.5.16	Debit cards	H
2.5.17	Credit Memo	H
2.5.18	Capture the following payment data, at a minimum:
2.5.19	Receipt or transaction ID (automatically generated)	H
2.5.20	Date/time	H
2.5.21	Payer (Customer ID) and description	H
2.5.22	Receivable invoice number(s) being paid	H
2.5.23	Amount paid by payment type (cash, check, money order...)	H
2.5.24	Type reference number (check number, credit card number, etc.)	H
2.5.25	Automatically apply the account code distribution from the receivable invoice(s) being paid, and allow the user to edit the accounts as necessary	H
2.5.26	Provide the ability to import receivable payments from a spreadsheet or other formatted file and apply the appropriate edit checks to validate the transactions	H
2.5.27	Accept an electronic media form of payment (including details regarding charges and fees from a variety of external sources including interfaces to other systems and electronic commerce)	H
2.5.28	Provide the ability to support a bi-directional interface or a bi-directional file transfer from the RTD point-of-sale system	H
2.5.29	Support PCI compliant transactions, e.g. for credit card payments	M
2.5.30	Provide the option to apply the payment to the oldest invoice or past due invoice first or slect which invoice to apply payment	L
2.5.31	Provide ability to perform offseting payables ("netting") against receivables with the same business partner	H
2.5.32	Provide a method of processing pre-payments and credit balances for a customer	H
2.5.33	Provide a method of reversing and re-applying payments that have been applied to the wrong invoice in error	H
2.5.34	Provide default chart of account distributions for specific payment types or receipts, such as various revenue and cash receivables without a receivables balance	H
2.5.35	Process split or mixed tendering situations (i.e., cash and check)	L
2.5.36	Support Non-Sufficient Funds (NSF) processing, including the generation of transactions to record reversal of original payment entries and add NSF fees to amount due	M
2.5.37	Provide the option to automatically update GL accounts or to batch receipt transactions for review and approval before posting to GL	L
2.6	Collections and Write-offs - Support collection of delinquent accounts and write-off of uncollectable accounts
2.6.1	Provide the ability to query or report delinquent account listing, and to drill down to full customer or invoice detail	H
2.6.2	Provide the ability to generate automatic notifications to designated RTD staff when customer accounts become delinquent	M
2.6.3	Provide the ability to automatically calculate and apply interest to an invoice amount based on RTD-defined interest rate and receivable type for a customer and/or invoice	H
2.6.4	Support TIN matching integration with W9 submission	M
2.6.5	Provide the ability to waive penalties and/or interest for a customer or invoice with approval workflow	M
2.6.6	Allow RTD to define and store multiple dunning letter formats based on the type of customer and receivable	H
2.6.7	Allow RTD to specify if dunning letters are to be sent, and the format by account, customer, project, or account type	H
2.6.8	Automatically generate dunning letters for accounts delinquent beyond a number of days specified by RTD (such as 30, 60, 90 days) for accounts with dunning turned on	H
2.6.9	Provide the ability to distribute dunning letters through email or paper.	H
2.6.10	Provide the ability to send an account to a collection agency for collections	L
2.6.11	Allow the user to define a write-off dollar threshold where overdue receivables for amounts under the threshold are automatically written-off by transaction, and where overdue receivables for amounts over the threshold are considered for collection	L
2.6.12	Provide a listing of potential write-offs falling within a user-defined criteria with the ability to accept or reject each entry and then process the selected items as a batch	L
2.7	Accounts Receivable Aging Analysis and Reporting - provide comprehensive and flexible reporting for AR
2.7.1	Provide an aging analysis of outstanding accounts receivable based upon user-defined aging buckets (e.g., 30, 60, 90, 120, and greater than 120 days) by receivable type using the original invoice date and current system date or a user-specified date	H
2.7.2	Allow a user to view and report on complete account history by customer	H
2.7.3	Provide a report by account of open receivables and account balances with detail, filtered by customer type, customer, receivable status, and/or receivable type	H
2.7.4	Produce a report of payments, adjustments, credit memos, write-offs, etc. posted by receivable type or GL acct number	H
2.7.5	Provide a revenue receipts report by customer and account	H
2.7.6	Generate a daily cash deposit report (cash, checks)	H
2.7.7	Provide a cash receipts report by type of revenue	M
2.7.8	Provide a list of receivables written off by date range, receivable or customer type	M
2.7.9	Provide report of all customers and accounts past due	H
2.7.10	Provide report of all receivables referred for collection	H
2.7.11	Provide a report of all imported payment transactions by source	H
2.7.12	Provide for download of AR data in various file formats (e.g., Excel, CSV, Comma-delimited, XML or other commonly accepted formats)	H
2.7.13	Retain historical information and maintain on-line access to a number of years of detail and summary data up to the limits that are defined in the RTD retention policy	H
2.7.14	Provide sales report listing all sales transaction detail for a date range, customer, product	M
2.7.15	Report credit card receipts/fees by account	L

3. AP

ERROR:#VALUE!	Denver RTD ERP Functional & Technical Requirements: 3.0 Accounts Payable		CONFIDENTIAL
ID	Final Requirement Statement	Priority (HML)	Vendor Response	Customization Estimate, if Applicable	Capability Planned for Future Release	Sub-Module(s) Name (Must match licensed sub-module in cost worksheet A.1 and B.1)	Applicable Third Party Solution(s)	Comments/Notes
3	Accounts Payable (AP): Provide full Accounts Payable functionality and to serve as the system of record for all RTD payables
3.1	Vendor Management (AP) - provide the ability to manage vendors for for the purpose of invoicing and payment for goods and services. (Also see Purchasing)
3.1.1	Provide the ability to enter and store reference information for vendors in a single vendor file to support all business functions, including purchasing and accounts payable	H
3.1.2	Vendor information shall include, at a minimum, the following:
3.1.3	Vendor ID (assigned automatically by the system)	H
3.1.4	Vendor Name	H
3.1.5	Multiple vendor addresses with a primary location designated	H

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated Jul 27, 2026.