attachment-2-rfp-2026-nhed-bsfin-01-q---a.pdf

RFP 2026-NHED-BSFIN-01

Vendor Q A - Question Cross Reference

Question # Description Related Questions 1 # of COAs, financial software 2 Timing of data 2, 8 3 System Support 3, 85, 87, 119, 123, 124, 125 4 Historical data - quality and completeness 4, 90 5 Users 5, 86, 92, 122 6 RFP - Pricing 7 BI Dashboarding Tool Access 8 Timing of data 2, 8 9 RFP - Vendor Comments Column

10 RFP - Pricing 11 RFP - Pricing 12 RFP- Format 13 5-digit School ID Number 14 Test Data - COA mapping 15 Crosswalking - Semantics 16 Preferred Platform 17 Vendor Conference Recorded 18 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 19 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 20 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 21 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 22 Technical - Security Audits 23 UCOA - changes 23, 70, 101, 115 24 Crosswalks - Custom 24, 41, 68, 113 25 Crosswalks - functionality 25, 67, 69 26 External Systems - Interface 26, 77, 78, 116 27 Technical - Single Sign On 27, 91 28 Historical data - technical 28, 50, 75, 93 29 Historical data - live or archive 30 Use of AI 31 Data Privacy 31, 57, 117 32 RFP - Pricing 33 Pricing - Years 4 - 7 33, 106, 121 34 UCOA Rollout 34, 38, 40, 71, 83, 107 35 Grant Extension 36 RFP - Pricing 37 RFP - Vendor Workbook 38 UCOA Rollout 34, 38, 40, 71, 83, 107 39 Batch/manual submission vs API 40 UCOA Rollout 34, 38, 40, 71, 83, 107 41 Crosswalks - Custom 24, 41, 68, 113 42 SIS Integration 42, 43 43 SIS Integration 42, 43

Question # Description Related Questions 44 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 45 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 46 Technical - data warehouse platform 47 Technical - documented reference architecture 48 Peak Users 48, 88

49 API

50 Historical data - technical 28, 50, 75, 93 51 CEDS/IDS mapping 52 Mapping Historical Data 52, 74, 104, 114 53 Technical - Web Service Required 54 Technical - Security Baselines 55 Support Response Time 56 Privacy - Self Certification 57 Data Privacy 31, 57, 117 58 RFP - Scoring 59 RFP - collaboration 60 Size of districts COA 61 Validations 61, 81, 89 62 RFP- preliminary scoring 63 RFP- preliminary scoring 64 RFP - Delivery Method 65 RFP- Submission 66 RFP - App B 67 Crosswalks - functionality 25, 67, 69 68 Crosswalks - Custom 24, 41, 68, 113 69 Crosswalks - functionality 25, 67, 69 70 UCOA - changes 23, 70, 101, 115 71 UCOA Rollout 34, 38, 40, 71, 83, 107 72 Use of Sample Data 72, 120 73 Legacy Reports 73, 80, 108 74 Mapping Historical Data 52, 74, 104, 114 75 Historical data - technical 28, 50, 75, 93 76 Historical data migration 77 External Systems - Interface 26, 77, 78, 116 78 External Systems - Interface 26, 77, 78, 116 79 Github 80 Legacy Reports 73, 80, 108 81 Validations 61, 81, 89 82 Dashboards 83 UCOA Rollout 34, 38, 40, 71, 83, 107 84 Acceptance Criteria 85 System Support 3, 85, 87, 119, 123, 124, 125 86 Users and volume assumptions 5, 86, 92, 122

Question # Description Related Questions 87 System Support 3, 85, 87, 119, 123, 124, 125 88 Peak Users 48, 88 89 Validations 61, 81, 89 90 Historical data - quality and completeness 4, 90 91 Technical - SSO 27, 91 92 Users 5, 86, 92, 122 93 Historical data - technical 28, 50, 75, 93 94 Foreign personnel 95 DFRS - future 95, 99, 118

96 DFRS

97 System integration 97, 98 98 System integration 97, 98 99 DFRS - future 95, 99, 118

100 Cost 101 Appendix A finalized? 23, 70, 101, 115 102 Arrival at the UCOA 103 RFP - page limits for App B 104 Mapping Historical Data 52, 74, 104, 114 105 RFP - Pricing 106 Pricing - Years 4 - 7 33, 121 107 UCOA Rollout 34, 38, 40, 71, 83, 107 108 Legacy Reports 73, 80, 108 109 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 110 Technical - Hosting 18, 19, 20, 21, 44, 45, 109, 110 111 Technical - Service 112 Technical - Service Credit Calculation 113 Crosswalks - Custom 24, 41, 68, 113 114 Mapping Historical Data 52, 74, 104, 114 115 UCOA - changes 23, 70, 101, 115 116 External Systems - Interface 26, 77, 78, 116 117 Data Privacy 31, 57, 117 118 DFRS - future 95, 99, 118 119 System Support 3, 85, 87, 119, 123, 124, 125 120 Use of Sample Data 72, 120 121 Pricing - Years 4 - 7 33, 121 122 Users 5, 86, 92, 122 123 System Support 3, 85, 87, 119, 123, 124, 125 124 System Support 3, 85, 87, 119, 123, 124, 125 125 System Support 3, 85, 87, 119, 123, 124, 125 126 Effective Training Methods

VENDOR Q & A

Question #1: Can you provide information on the number of unique local Charts of Accounts in use across districts and the main financial systems being used?

Answer:

Public School Districts

New Hampshire has 105 School Administrative Units. SAUs can be single district or multi-district. There are 179 school districts. An SAU most likely has a chart of accounts that is similar across each of its districts, but there could be nuances.

Within public-school districts, there are nine public school districts that are “dependent” cities, meaning that their chart of accounts is housed within the financial system of a larger municipal entity.

Of public-school districts, most use Tyler Technologies School ERP Pro, but districts also use Munis, Linq, Profund, eFinance Plus, and a host of other software.

Financial Software %

School ERP Pro 60%

Munis 13%

Linq ERP 5%

Profund 4% eFinance Plus 4%

Other (7) 5%

Unknown 8%

Total 100%

Charter Schools

New Hampshire has 36 charter schools. The software that is being used by charter schools has not been surveyed. The OƯice of Charter Schools believes that Quickbooks is the most prevalent.

Question #2: What is the typical lead time needed to obtain data extracts from districts, and how does the Agency expect to coordinate data extraction, mapping, loading, and reconciliation?

Answer:

School finance data is due to the Bureau of School Finance (BSF) annually with a September 1st deadline for the fiscal year ending the prior June 30th. One-month extensions may be granted to adjust the deadline further out. Extensions can only be granted so far out as districts need completed financial data for the State of New Hampshire to be confident in the tax rate. All financial data is typically finalized in December.

The BSF can assist a district with uploading the data, answering mapping questions, using the software, and identifying flaws in the data that need to be fixed. The BSF cannot change the underlying data in the district’s general ledger software. The district is required to maintain proper and accurate accounting records, map any deviations from their local chart of accounts to the State’s chart of accounts, and produce a file for upload. The BSF is available to troubleshoot challenges as the district completes that work.

Related questions: 2 and 8

Question #3: What level of NHED staƯ involvement is expected to support data loading, reconciliation, district onboarding, and certification during the pilot and rollout phases?

Answer:

NHED staƯ primarily performs a trouble shooting and problem-solving role. It is the district’s responsibility to make their data amendable to State reporting. However, as questions or challenges come up at the local level, NHED can walk through the district as to what the final product should look like and provide guidance on how to achieve that objective.

The vendor will be highly involved in the technical support of the application during the pilot year and 20-district rollout the following year. Eventually, district application support will be transferred to the BSF; BSF will need technical support from the vendor.

BSF is expected to have approximately 1.5 full-time equivalent employees dedicated to coordinating the rollout relative to software deployment and engaging with users throughout the pilot program.

Related questions: 3, 85, 87, 119, 123, 124, 125

Question #4: On a scale of 1-5, with (5) being excellent and (1) being very bad, how would you rate the quality and completeness of the 10 years of historical data currently maintained in Excel and SQL formats?

Answer:

The Agency rates the completeness of the 10 years of historical data as 5. All districts are required to submit data for the tax rate setting process.

The Agency rates the quality of the data as 4 as it can provide context for general trends and performance of districts. The data currently goes through quite a bit of automated and manual validations but is not audited. For example:

The balance sheet must balance

Revenues must match state records

Beginning balances of fund balance must match prior year ending balance

Each data submission is reviewed by a BSF employee, and the file is returned based on a quality review. However, there are errors that can happen due to the manual nature of the input. In addition, the BSF would like to collect more granular data, rather than the data rolled up by function and object code.

Related questions: 4 and 90.

Question #5: Can you provide an estimate of the number of users by type (NHED staƯ, district users, read-only, etc.)?

Answer:

Estimated number of state users: <30 Estimated number of district users: 860 (4 per district: SEO, SFO, IT Director, Support).

Estimated number of district and state administrators: <10 State administrators Estimated number of public users: Not applicable until the creation of dashboards

Related questions: 5, 86, 92, and 122.

Question #6: Should the pricing be aligned to the actual contract start date following Governor and Council approval, or to the periods shown in the pricing worksheets?

Answer:

It would be helpful to align the first year of pricing to the period ending September 27, 2027, which is the oƯicial end data of the grant. Governor and Council approval may occur in the January timeframe, so the first year of the contract would run January (TBD) through September 27, 2027.

Question #7: Does the Agency currently have access to a business intelligence or dashboarding tool (such as Power BI) that could be used for the public transparency dashboards, or should the vendor include licensing for such a tool?

Answer:

Yes, the Agency currently publishes public reports and dashboards via Tableau, so that is an option. However, alternate public dashboard tools will be considered.

Question #8: Are there any key deadlines related to tax rate setting that the implementation timeline should align with?

Answer:

Tax rate setting is an annual process that occurs in the fall. The process uses the data from the DOE-25 Report (MS-25 is an extract from this file sent to the Department of Revenue). That is why the data is required to be submitted by September 1st (or October 1st with a formal extension request). By October 1st the State is ready to set tax rates, if the district has provided quality information to be used in the tax rate setting process.

Related questions: 2 and 8

Question #9: Page 41: Are there any specific instructions for the Vendor Comments Column?

Answer:

The Vendor Comments column does not have any requirements, rather it allows the vendor to input anything that may help clarify the Y/N column and the Delivery Method columns.

Question #10: According to page 18 "The Price Proposal must be labeled clearly and submitted separately from the Technical Proposal." Do you want Appendix E's tab from the RFP 2026-NHED-BSFIN-01 Vendor Workbook to be extracted and submitted as its own Excel/PDF file? Does "separately" mean a separate attachment or a separate email?

Although all appendices were included in one file, please extract Appendix E and submit it as a separate excel document.

Question #11: Pricing: Does NHED want a Price Proposal narrative or anything other than Appendix E?

Answer:

Please complete Appendix E for pricing and feel free to include anything further that you would like to consider regarding pricing, if it is clearly labeled as pricing and kept separate from the rest of the proposal.

Question #12: Submission Format: Does NHED want the Appendices found in the RFP 2026-NHED-BSFIN-01 Vendor Workbook submitted in Excel or PDF format?

Answer:

Please submit the Appendices in Excel for Appendix C through E.

Question #13: I understand the school id in the UCOA is 3 digits. How does that relate to the 5-digit school IDs currently used by the state?

Answer:

The UCOA will have school IDs as 2 digits, the state recognized school IDs are 5 digits. The Agency envisions the new application/system to allow the districts and charters the ability to map their two-digit ID to the state recognized 5-digit ID. The Agency would display all the 5-digit IDs for districts/charters that they would have to map to the two-digit ID for each fiscal year.

Question #14: Does the test data have a mapping conversion from local COA to UCOA?

Answer:

No.

Question #15: For master data items like this, is the goal for the schools to be able to map or to be managed behind the scenes.

Answer:

It is expected that districts will need to map because they maintain a diƯerent chart of accounts in their local software that is diƯerent than the State’s chart of accounts.

Districts typically want maximum flexibility, and the State typically wants to standardize as much as possible. Districts will need flexibility to map as they adjust their chart of accounts. Ideally, a district would only have to set up mapping once or they would adjust their local chart of accounts, so mapping is not necessary. The State will also want override capability to map after the district has submitted their data to NHED.

Question #16: Beyond the state-owned SQL database, are there any preferred platforms being evaluated or existing parts of the technology stack that should be extended (data warehouse, ETL solutions)?

Answer:

The Agency is not committed to a preferred solution. The Agency is open to expanding the on-prem SQL server or having the solution as an external system, for example. We’ve recently done both methods of expanding the system and new, external systems that communicate to the internal system via FTPs and APIs.

Question #17: Is this meeting being recorded and if so, can we get a copy of it alongside the supporting documents?

Answer:

No, the meeting is not recorded. The PowerPoint slides will be sent out to attendees’ post conference.

Question #18: Is NHED open to vendor-hosted solutions, or would you prefer the system be custom-built inside your own current infrastructure?

Answer:

The Agency is open to external solutions as well as expanding the existing internal system.

We’ve recently done both methods of expanding the system and new, external systems that communicate to the internal system via FTPs and APIs. NHED would just want to ensure full access to the data.

Related questions: 18, 19, 20, 21, 44, 45, 109, 110

Question #19: Does DoIT prefer, or restrict against, a specific public cloud (Azure vs.

others), given Appendix F describes a VMware / Oracle environment?

Answer:

Oracle, Azure, AWS, and GCP are all compliant with GovRAMP, NIST, etc. and are all viable solutions.

Related questions: 18, 19, 20, 21, 44, 45, 109, 110

Question #20: Will the State accept a fully vendor-hosted cloud solution residing in the vendor's Azure tenant, with NHED accessing via permission-based logins — or does DoIT require the application to be hosted within the State's own environment?

Answer:

The application does not need to be hosted in the State's environment.

Related questions: 18, 19, 20, 21, 44, 45, 109, 110

Question #21: If the State is open to a cloud vendor-hosted solution, what are DoIT's specific requirements for how an external-cloud-hosted system connects to the on-prem data warehouse and state-owned SQL database (VPN, Private Link, ExpressRoute, IP allow-listing)?

Answer:

This is a complex question and is highly dependent on several factors, e.g., type of data transferred (FERPA, PII), the methods used to transfer/transmit the data (VPNs, encryption), etc. This is a security design discussion and would most likely require a more detailed conversation with the infrastructure and security teams.

Related questions: 18, 19, 20, 21, 44, 45, 109, 110

Question #22: Will the State require the vendor to authorize its security audits / vulnerability assessments against the vendor's production Azure tenant, and at what cadence?

Answer:

This will be monitored at the Department of Information Technology’s discretion. For any resulting award(s) and subsequent contract(s), the awarded contractor(s) will grant access to continuous monitoring and reporting upon receiving award for GovRAMP Security Snapshot, Ready status and Authorization status through the life of the contract. The State reserves the right to request and review all Third-Party Assessment Organization (3PAO) audits, risk assessments, vulnerability assessments, and penetration tests of the contractor's environment. The contractor shall respond to all flaws discovered by providing a mutually agreed upon timeframe to resolve the issue and/or implement a compensating control.

Question #23: The UCOA is being developed under the Bureau's separate chart-of-accounts workstream. As of contract start, will the UCOA structure and segment definitions be finalized and provided to the vendor as a fixed specification, or should the vendor expect future changes?

Answer:

The account code definitions should be finalized by contract start. However, the Agency anticipates future changes to these codes because of accounting rules, federal code changes, NH legislation which aƯects the codes, or clarification of codes. The account code string (UCOA) should be final by contract start.

Related questions: 23, 70, 101 and 115.

Question #24: For districts that cannot adopt the UCOA, does the State expect the crosswalk to be a permanent submission path indefinitely, or a transitional aid?

Answer:

The Agency anticipates both scenarios. There are 9 “dependent” cities that may require a custom crosswalk outside of the universal crosswalk tool as their financial data resides within a municipality and they do not have the ability to switch to a UCOA. Most districts will use a crosswalk transitionally until they can adopt the UCOA.

Related questions: 24, 41, 68, and 113

Question #25: Are there known cases where a single district account code must map to multiple UCOA segments (one-to-many), and does the State have a set expectation on handling missing segments (e.g., school-level detail)?

Answer:

There may be instances where public school district data contains a component of their account code string that maps to more than 1 segment. For example, a school district may have a four-digit code that represents account type (1 digit) followed by a three-digit object code. If a district has segments missing from their account code string, they will need to add that data in during their crosswalk process.

Related questions: 25, 67 and 69

Question #26: What are the available interface methods for iNHDEX, GMS, the state SQL database, and the DOR Municipal Tax Rate Setting Portal — API, file exchange, direct DB — and which are mandatory vs. preferred for this contract term?

It is preferred that an interface method exists to allow for the capability of automation in bringing in data. The Agency envisions having to use a file exchange at the onset of the project but is open to more eƯective solutions in the future, such as API.

Related questions: 26, 77, 78, and 116

Question #27: What are the acceptable methods for Single Sign-On for the State (e.g., SAML)?

Answer:

The State supports SAML. See also Question 91.

Question #28: For the historical data migration, in what condition and formats does it currently exist (Excel, SQL schema), and will the State make a complete extract available at project start?

Answer:

The existing data resides in SQL schema but can be exported as CSV or Excel.

Related questions: 28, 50, 75, and 93.

Question #29: Is all 10 years required to be loaded into the system as live retrievable real-time data, or is some of it acceptable as archive-only or aggregate-only?

Answer:

The Agency would like the data as live retrievable data for ad-hoc historical analyses.

Question #30: Does the State or DoIT have policies governing the use of AI / LLM services on State data — including approved providers, in-tenant processing requirements, and data-retention or model-training restrictions as part of the solution or finance system? (e.g., to assist users during cross-walking to UCOA)

Answer:

A more detailed discussion would occur on a case-by-case basis, which would need to take place. Typically, the Agency requires that all potential AI / LLM eƯorts be vetted with the CIO and CISO. Generally, the State does not authorize the use of State data to feed AI / LLM models.

Question #31: Beyond FERPA, HP1612, and RSA 359-C, are there additional NH data-handling or breach-notification requirements the solution must meet?

School finance data are public records. As such, additional data breach requirements beyond those stated are not anticipated.

Related questions: 31, 57 and 117.

Question #32: How does the State want the Appendix E pricing split for contingent (extension-year) pricing to be represented; is the project to start Year 1 (this year 2026) or Year 1 of extension-year?

Answer:

The Appendix E pricing proposal lists the deliverables for each period: Year 1 through 9/27/2027, Extension Year 1, and Extension Year 2. The matrix indicates which deliverables correspond to each period with boxes that have a border with yellow highlights.

Question #33: Does the “Year 4–7” pricing column represent a single combined period, and should ongoing support for those years be priced there as one chunk for all 4 years?

Answer:

The amount entered under Year 4 – 7 should be one aggregate number for all four years: 4, 5, 6, and 7 for each of the components listed: hardware, software, hosting, staƯing, support, other and total.

Related questions: 33, 106, and 121

Question #34: After the initial pilot (6) and rollout (20 districts), what are the State's expectations for statewide rollout within the contract term vs. via the implementation playbook?

Answer:

The goal is to have 6 districts pilot the system during the first extension year and 20 additional districts migrate to it during the second extension year. Ultimately, a full rollout is expected. Some districts may be well-positioned for immediate rollout where others may need additional time & support.

Related questions: 34, 38, 40, 71, 83 and 107

Question #35: Will the federal grant timeline (expiry Sept 27, 2027), possible two-year extension) impose any constraints on deliverable scheduling?

The Agency expects that the federal grant will be extended for the full 2-year extension periods. This confidence stems from previous experience with the FY19 SLDS grant that was also extended for 2 additional years.

Question #36: Can you clarify if the price proposal should consider all the vendor work to be fully completed in Year 1 (from Jan 2027 to Sep 2027)? In case the extension is not granted for the additional 2 years that NHED has everything completed, including a written implementation plan, that NHED would carry out on their own? Or should we price it as a 3-year project with vendor involvement in all 3 years?

Answer:

Price it as a 3-year project with vendor involvement in all 3 years.

Question #37: Is the referenced “Vendor Workbook” (Appendices C, D, E) available now, and if so, can the Agency share the link?

Answer:

Please find the RFP at this URL:

https://apps.das.nh.gov/NHProcurement/Bid/rfp-2026nhedbsfin01

The Request for Proposal has links throughout the document to the vendor workbook, for example see Page 56.

Question #38: What percentage of districts are expected to be on the UCOA (vs.

legacy/cross walked COA) by the end of the base contract term?

Answer:

The goal is to have 6 districts pilot the system during the first extension year and 20 additional districts migrate to it during the second extension year.

Related questions: 34, 38, 40, 71, 83 and 107

Question #39: Is real-time API-based data submission required at go-live, or is batch/manual submission acceptable through the base term, with API access required only for outbound data?

The Agency envisions that a batch/manual submission process will be required at the beginning of the project, with an eventual migration to API or further automation.

Question #40: Is statewide rollout to all ~200 districts expected within the base 2-year term, or is it expected to extend into the optional extension period?

Answer:

The strategy is to pilot 6 districts in the first extension year, followed by 20 districts during the second extension year.

Related questions: 34, 38, 40, 71, 83 and 107

Question #41: Who authors and maintains each district's crosswalk map — the district, the Agency, or the vendor? If the vendor is building maps for the 6 pilot and 20 rollout districts inside the Extension Year pricing, what per-district eƯort should be assumed for the remaining ~174 districts?

Answer:

Ultimately, it is the district’s responsibility to get data in the form of the UCOA under this new system. To the extent that a universal crosswalk tool can be employed, the Agency is looking for guidance and instruction on how this could be done. The Agency does not envision building individual crosswalks for all the districts and charters as this will be universal crosswalk tool. District and charter schools will manage and maintain their mapping using the universal crosswalk tool. There are 9 “dependent” cities that may require a custom crosswalk outside of the universal crosswalk tool as their financial data resides within a municipality and they do not have the ability to switch to a UCOA. Most districts will use a crosswalk transitionally until they can adopt the UCOA.

Related questions: 24, 41, 68, and 113

Question #42: SIS integration is Mandatory while SSO, iNHDEX, Special Education, Food/Nutrition, and Grant Management integrations are Preferred — can the Agency confirm relative priority, and will API specs for these systems be shared before proposals are due?

Answer:

Integration with the data warehouse (SIS) is required under the Data Dashboard section of Appendix C, Section 1. SSO, Special Education, Food/Nutrition, and Grant Management Systems are part of the data warehouse. Currently data is imported from iNHDEX to the data warehouse. NHED will be responsible for moving the data from its systems to the appropriate location in the data warehouse.

Related questions: 42 and 43

Question #43: Which specific Student Information System(s) must the Solution interface with?

Answer:

The only integration is with the State’s SIS.

Related questions: 42 and 43

Question #44: Does the Tier 3 data center requirement apply to multi-tenant cloud/SaaS hosting, or does the Agency require dedicated/single-tenant hosting?

Answer:

The Agency would not require dedicated/single-tenant hosting. It does apply to multi-tenant cloud/SaaS hosting.

Related questions: 18, 19, 20, 21, 44, 45, 109, 110

Question #45: Is fully vendor-hosted cloud hosting acceptable, or is there a preference for hosting within/connected to DoIT infrastructure?

Answer:

The Agency does not prefer a hosting solution and is open to all solutions. It is essential the NHED maintain real-time full access to the data.

Related questions: 18, 19, 20, 21, 44, 45, 109, 110

Question #46: What platform is NHED’s on-prem data warehouse (for ETL/export), and is existing integration middleware already in place?

Answer:

The platform is Microsoft SQL Server. Middleware does not exist for the current financial data warehouse. Microsoft SQL is the server, SSIS for ETL.

Question #47: Is a documented reference architecture for NHED’s tech stack available to inform environment design?

Yes, and will be shared once a contract is in place.

Question #48: All ~200 districts submit against a single September 1 statutory deadline. What peak concurrent user count and submission-window profile should the Solution be sized and load-tested against, and are there performance acceptance criteria the System must pass before Acceptance?

Answer:

The Agency expects peak load not to exceed 50 users concurrently and for submissions to be processed within a minute.

Related questions 48 and 88

Question #49: Would REST/JSON APIs satisfy the “open standards access protocol” requirement, or is a specific protocol expected?

Answer:

No specific protocol is expected if APIs are used.

Question #50: What SQL platform holds the 10 years of historical data, and is a data dictionary/schema available for migration planning?

Answer:

10 years of historical data reside on a Microsoft SQL Server and NHED will provide a data dictionary (account code classifications) by contract start.

Related questions: 28, 50, 75, and 93.

Question #51: Has CEDS/IDS mapping via GENERATE been scoped internally, or is this greenfield?

Answer:

Yes, the CEDS/IDS mapping has been scoped internally.

Question #52: The Scope of Work makes "map and archive 10 years of historical data" Mandatory, while the vendor conference lists "Historical data mapped to current definitions" as Preferred. Must ten years of legacy DOE-25 data be restated into the UCOA, or archived in its original structure with UCOA mapping applied only from go-live forward?

It is mandatory that 10 years of historical data be mapped to the UCOA. This should not be too heavy of a lift as the historical data was captured via roll-up. However, there are large data mappings such as:

Data with 1400 function codes would need to map to the 1900 function code series Data with 2800 function codes would need to map to the 2500 function code series

It is not essential to get this historical data immediately. Rather, building out a solid method for data collection and storage is priority 1.

Related questions: 52, 74, 104, and 114

Question #53: What is the specific latency/SLA target behind the “near real time” web services requirement?

Answer:

For the scope of this project, real time would be within 24 hours.

Question #54: Will DoIT’s current security hardening baselines (CIS/NIST/NSA) be shared during the inquiry period?

Answer:

Detailed security hardening standards will be shared at the point of contract.

Question #55: Does the 2-hour Class A response time apply 24/7, or only during the 8:30–5:00 EST support window?

Answer:

Response time of two hours of a request during the hours of 8:30-5:00 EST is acceptable.

Question #56: Is a third-party accessibility audit/VPAT required, or is self-attestation of FERPA/HP1612/ADA-508 compliance suƯicient at proposal stage?

Answer:

A self-attestation would be suƯicient at the proposal stage.

Question #57: The public-facing dashboard must "query, extract, roll up, suppress, aggregate and export data based on user profile." What suppression thresholds apply (small-cell or FERPA-driven), is public access anonymous or authenticated, and what public concurrency should be sized for, particularly around tax rate setting season?

All data is financial and public. The Agency does not plan to provide any sensitive data in the public facing dashboards.

Public access via the published dashboard for public is anonymous as any citizen may access it.

Less than 15 State users would need real-time access to most current completed DOE25 during tax rate season to ensure a timely tax rate.

Related questions: 31, 57 and 117.

Question #58: In scoring the 3 prior-project references, does the Agency weight domain similarity, project size, or recency most heavily?

Answer:

No weighting is prescribed in the rubric.

Question #59: If a vendor proposes with a subcontracted ISV/systems integrator as one unified solution, is that treated as a single Proposal?

Answer:

Yes.

Question #60: The sample district has 861.74 ADMA, approximately $18.9M in expenditures and 1,706 general ledger rows and is described as a small district;

Manchester is listed at 11,644 ADMA. What annual transaction volume should vendors size for expected rows per district at the largest tier, and total statewide rows per submission cycle? Is there a maximum file size or row count per district submission?

Answer:

The size of a district’s COA depends on the segments they are currently using. For example, districts that use subject codes have a large chart of accounts. Likewise, districts which have many individual schools would also have a large chart of accounts.

The largest districts would have a chart of accounts that are significantly higher than the data presented. See also Question 86.

Question #61: The sample workbook contains conditional accounting rules that are not described in the RFP text, including the School Level Expenditures schedule required for Federal OƯice of Civil Rights compliance with a forced zero variance against DOE-25 pages 7 and 11, indirect cost computation per 34 CFR 76, and the

2,500 ADMA threshold governing superintendent cost treatment. Will the Agency provide a documented catalogue of validation and accounting rules, with expected counts, prior to contract, or is rule discovery a vendor responsibility during Year 1?

Answer:

BSF will provide a catalog of validation rules at the start of the contract. Validations will be a dynamic process.

Related questions: 61, 81, and 89

Question #62: Technical-gate calculation: Please clarify how the minimum preliminary technical score of 70 will be calculated. Is the score of 70 measured collectively across Data Process, Data Reporting, Data Submission, Data Validation, Data Consolidation, Data Crosswalk, and Data Dictionary, or must a vendor achieve a score of 70 within each identified category?

Answer:

NHED will review the technical proposals related to Data Process, Data Reporting, Data Submission, & Data Validation, Data Consolidation, Data Cross-Walking, and Data Dictionary. These categories have a maximum number of points of 150. A minimum score of 70 out of the 150 points must be scored for the proposal to move forward.

Question #63: Mandatory-requirement threshold: Please explain how the requirement to provide at least 80 percent of the mandatory requirements will be calculated, particularly when a single Appendix C or Appendix D workbook row contains multiple capabilities. Will the percentage be calculated by workbook row, individual capability, category, point value, or another method?

Answer:

It will be calculated at the workbook row level.

Question #64: Standard versus configured functionality: Appendix C states that “Yes” may be used only when a capability is Standard and does not require special customization. May functionality delivered through ordinary product configuration, workflow design, report configuration, standard APIs, or standard connectors be classified as “Yes/Standard,” provided that no custom source-code development is required?

Yes.

Question #65: Supporting narratives and attachments: May vendors cross reference a single supporting narrative, architecture diagram, demonstration artifact, or other supplemental attachment from multiple Appendix C and Appendix D workbook rows, rather than repeating the same information in each comment field?

Answer:

Yes.

Question #66: Appendix B submission format: The RFP describes Appendix B deliverables primarily as narratives and supplemental materials, while the vendor-conference presentation identifies Company Profile Information as an Excel-spreadsheet submission. Please confirm whether Appendix B responses should be included in the technical-proposal narrative, entered in the Vendor Workbook, submitted as attachments, or provided in more than one location.

Answer:

Appendix B responses are part of the technical proposal. However, they do not lend themselves well to the spreadsheet. The spreadsheet for Appendix B is included to give the vendors a sense of what criteria the Agency will be using to assess the vendor:

credentials, financial strength, litigation, prior projects, team organization, staƯing, project manager, project execution, communication/training/support, migration strategy. If the vendor finds the spreadsheet helpful to cross-reference other materials supplied, please feel free to do so.

Question #67: Minimum crosswalk functionality: Please describe the minimum functionality expected of the universal local-COA-to-UCOA crosswalk. Should the solution support one-to-many and many-to-one mappings, eƯective dates, fiscal-year versioning, reusable mapping rules, exception handling, review and approval workflows, audit history, and preservation of the original district account code?

Answer:

Yes, the universal crosswalk tool needs this functionality:

one-to-many many-to-one mappings eƯective dates fiscal-year versioning reusable mapping rules exception handling review and approval workflows audit history preservation of the original district account code

Related questions: 25, 67 and 69

Question #68: Responsibility for district mappings: What allocation of responsibility should vendors assume among NHED, the vendor, and each district for creating, reviewing, approving, correcting, and maintaining district specific local-COA-to-UCOA mappings?

Answer:

BSF envisions the creation of one universal crosswalk tool that districts can use to map their chart of accounts to the UCOA. There are 9 “dependent” cities that may require a custom crosswalk outside of the universal crosswalk tool as their financial data resides within a municipality and they do not have the ability to switch to a UCOA. Most districts will use a crosswalk transitionally until they can adopt the UCOA.

Related questions: 24, 41, 68, and 113

Question #69: Expected level of crosswalk automation: Does NHED expect the solution to suggest potential UCOA mappings, or is the intended solution a rules-based tool through which users manually establish mappings? How should the solution identify and process ambiguous, incomplete, invalid, or unmapped source account codes?

Answer:

A mapping tool that can identify errors or inconsistencies would be desired. If a code cannot map to the data dictionary, then an error message should be generated requiring a change in the account code by the user to be compliant with the State’s UCOA.

Related questions: 25, 67 and 69

Question #70: UCOA changes after award: The RFP states that the UCOA structure may change immaterially before contract negotiation. Please describe the anticipated change-control process and clarify how post-award changes to UCOA segments, codes, hierarchies, definitions, or accounting rules will be addressed within the Firm Fixed Price/Not-to-Exceed scope.

The State needs the ability to adjust account codes annually (UCOA segments) within the designed system (e.g., adding or deleting an expenditure function code, etc.). These changes are anticipated year-to-year to address governmental accounting rules or to fine tune or add accounts based on new legislation. The system should be designed to house an “annual” data dictionary. The UCOA string itself has undergone a vetting process and tested for automation. The Agency does not anticipate it changing. However, the Agency reserves the right to change it if needed.

The system also needs flexibility to be changed throughout the year. The Agency anticipates publishing these changes as “release notes” and making them available to users on a regular basis via the support infrastructure built upon Atlassian’s Jira Service Management & Confluence platform.

As for the anticipated change-control process, NHED anticipates regular and ongoing working sessions with the vendor where required changes will be discussed from both a business rules and development perspective. Low-level changes will be authorized at the discretion of the project manager, while critical changes pertaining to cost, time, scope, and risks will be negotiated. Where applicable, NHED and vendor may agree to limit specific values or quantities (i.e. “not to exceed a certain threshold”) to cap their exposure.

Related questions: 23, 70, 101 and 115.

Question #71: Scale of vendor mapping support: For pricing and staƯing purposes, how many district charts of accounts should the vendor expect to analyze or map during Year 1, the pilot involving up to six districts, and the subsequent 20-district rollout?

Answer:

Year 1: test data, Extension Year 1: 6 districts, Extension Year 2: 20 districts.

Related questions: 34, 38, 40, 71, 83 and 107

Question #72: Use of the sample-district data: Please confirm whether vendors are expected to use the supplied sample-district data in their proposals or demonstrations to show an end-to-end process from ingestion through cross walking, validation, certification, State approval, consolidation, and reporting.

Answer:

Vendors are encouraged to use the test data to present their solution in their proposal.

Related questions: 72 and 120

Question #73: Test-data acceptance outputs: What specific outputs should vendors produce from the sample data to demonstrate that the proposed solution meets NHED’s expectations, for example, mapped UCOA records, unmapped-account or exception reports, validation results, DOE-25 or MS-25 outputs, cost-per-pupil calculations, district profiles, or dashboard results?

Answer:

The Agency is looking for exact format reproduction of the current outputs at go-live for continuity and Department of Revenue compatibility, as illustrated in the TEST DATA file:

DOE-25 workbook with all supplemental schedules Cost per Pupil Calculations District Profiles With Errors/Warnings/Output based on validations

Federal extracts would also need to continue but the Agency is hoping to achieve a streamlined data submission process.

The Agency anticipates a defined path to a streamlined DOE-25 replacement eventually.

Note that the MS-25 Report which is derived from the DOE-25 tab is constrained by the Department of Revenue requirements outside of NHED’s control.

The Agency will design a dashboard to be implemented in Year 1 if the vendor includes this preferred element in their proposal.

Related questions: 73, 80 and 108

Question #74: Historical-data treatment: For the required ten years of historical data, should the solution preserve each year under its original definitions, associate each year with a year-specific data dictionary, map or recast historical data to the current UCOA, or provide both original and harmonized historical views?

Answer:

A single crosswalk applies to all ten years with a small number of named exceptions. The historical data will require mapping to the current UCOA. See related questions.

Related questions: 52, 74, 104, and 114

Question #75: Historical-data inventory: Please provide an inventory of the available historical Excel and SQL sources, including approximate record counts, file structures, database schemas, supporting attachments, available and missing years, known data-quality issues, and existing data dictionaries or technical documentation.

Answer:

The existing SQL solution is a relational schema. Most data are within <10 tables, while relatively minor amounts of data are across an additional ~50 tables. The existing database size of relevant data is approximately 2,000MB. This figure includes information the Agency may designate “unnecessary” to migrate to the new system. When exporting required information to be transferred into CSV files, the 10-year total records are a minimum of 5,852,000 and the total file size is a minimum of 500MB. File counts in the migration are unknown currently and are dependent on the coordination of NHED and the vendor. There are no known structural or completeness defects related to the data that would impact this contract. Additional details will be provided at point of contract.

Related questions: 28, 50, 75, and 93.

Question #76: Migration reconciliation: What reconciliation and acceptance criteria will NHED use for migrated historical data—for example, record counts, financial control totals, DOE-25 totals, district and statewide totals, account level comparisons, or report-by-report comparisons with DFRS?

Answer:

Migrated historical data must be at a 100% rate and validated one for one to the source record as submitted. The reconciliation criteria listed are acceptable reconciliation methods.

Question #77: Year 1 integration scope: Please identify which interfaces must be operational in Year 1 and which may be delivered in a later phase, including iNHDEX, the Grant Management System, Special Education, Food and Nutrition, Department of Revenue data, NHED Single Sign-On, the State data warehouse, GitHub, and district financial systems. For each interface, please provide approximate transaction or file volumes and indicate whether the expected integration pattern is real time, near real time, scheduled batch, or on demand.

For year 1, the Agency needs the ability to provide custom data integration via file exchange processes with all systems. DOE25 is done once a year. Therefore, all the submissions need to be done essentially once. However, revisions to the source data might change which would cause the data to be transferred more than once. Therefore, a few times between May and September, on-demand modifications to re-integrate the data would be needed.

NHED Single Sign-On – Preferred integration.

Grant Management System – Required to bring in external data from this system in year 1 by file exchange. Approximately 6,000 data elements. Integration beyond file exchange is preferred in future years.

Special Education - Required to bring in external data from this system in year 1 by file exchange. Under 4,000 data elements expected. Integration beyond file exchange is not required but preferred for future years.

Food and Nutrition – Required to bring in external data from this system in year 1 by file exchange. Under 4,000 data elements expected. Integration beyond file exchange is not required but preferred for future years.

Department of Revenue data – Required to bring in external data from this system in year 1 by file exchange. Under 4,000 data elements expected. Integration beyond file exchange is not required but preferred for future years.

State data warehouse (iNHDEX) - Required to bring in external data from this system in year 1 by file exchange. Under 4,000 data elements expected. Integration beyond file exchange is not required but preferred for future years.

GitHub - The ability to interface with GitHub is mandatory, although not expected for initial rollout of data collection.

District financial systems – not required

Related questions: 26, 77, 78, and 116

Question #78: Interface documentation: For each in scope integration, when will NHED provide interface specifications, data dictionaries, sample payloads or files, security and authentication requirements, update frequencies, test environments, data-owner contacts, and access to relevant subject-matter experts?

Answer:

The estimated timing of interface specifications is as follows:

Data dictionary – upon contract start Sample payloads – see Test data set. More test data will be solicited upon contract start

Security and authentication requirements – upon contract start Update frequencies – upon contract start Test environments – will be discussed upon contract start Data-owner contacts – will be discussed upon contract start Access to subject-matter experts – upon contract start

Related questions: 26, 77, 78, and 116

Question #79: Meaning of GitHub integration: Please clarify the required use case for the mandatory ability to interface with GitHub. Does this refer to source-code management, deployment automation, issue tracking, configuration management, document or file exchange, publication of artifacts, or another function?

Answer:

The Agency uses Azure DevOps as the SDLC with a standard DEV->TEST->UAT->PROD model. GitHub is used by Azure DevOps for source code management.

Question #80: Legacy-reports: Should the new system reproduce DOE-25, MS-25, supplemental schedules, cost-per-pupil calculations, district and State profiles, and federal extracts in the same layouts and formats used today, or may the vendor propose revised formats that produce equivalent data and calculations?

Answer:

The Agency is looking for exact format reproduction of the current outputs at go-live for continuity and Department of Revenue compatibility, as illustrated in the TEST DATA file:

DOE-25 workbook with all supplemental schedules Cost per Pupil Calculations District Profiles With Errors/Warnings/Output based on validations

Federal extracts would also need to continue but the Agency is hoping to achieve a streamlined data submission process.

The Agency anticipates a defined path to a streamlined DOE-25 replacement eventually.

Note that the MS-25 Report which is derived from the DOE-25 tab is constrained by the Department of Revenue requirements outside of NHED’s control.

The Agency will design a dashboard to be implemented in Year 1 if the vendor includes this preferred element in their proposal.

Related questions: 73, 80 and 108

Question #81: Authoritative calculation and validation rules: Will NHED provide authoritative formulas, business rules, accounting rules, account-combination rules, validation thresholds, suppression rules, rounding methods, and sample expected results for all State and federal reports and calculations?

Answer:

BSF will provide formulas and the validations thresholds and rounding methods upon contract. The Agency would like to continue all existing validations (e.g., account code, account code combination, accounting, business rules, etc.) as well as thresholds and rounding methods. The Agency will provide sample results for state and federal reports and calculations to ensure quality data.

Related questions: 61, 81, and 89

Question #82: Dashboard scope and governance: Which dashboards, metrics, and financial-risk indicators shown in Exhibit C are required for Year 1? Who will define and approve risk-rating logic, thresholds, peer-district groupings, public-data suppression rules, accessibility requirements, refresh frequencies, and future dashboard content?

Answer:

Exhibit C is provided for idea generation at this time, and these dashboards have not been finalized. The Agency will design a dashboard to be implemented Year 1 (preferred element in the RFP).