Standard Contract Reconciliation Tool (SCRT)

Questions & Answers / Clarifications

This document provides responses to questions submitted by potential vendors regarding the Sources Sought notice for the SCRT (System Control and Reporting Tool) technical refresh.

• Incumbent Contract: There is no incumbent contractor for this requirement.
• Technology Restrictions: Low-code/no-code platforms are strictly prohibited. Solutions like Appian are considered out of scope.
• Development Environment Access: Access to PowerBuilder 2019 R3 source code and Oracle 19c schema will only be granted post-award.
• Object Modernization: All identified PowerBuilder objects will need to be technically refreshed, as there is no current method to identify dormant or deprecated objects.
• Module Structure: DFAS intends to preserve the current 4-module structure (Registration, Compare, Adjustments, Reports). Enhancements or functional consolidations are not in scope.
• Cloud Deployment: Target solutions must be deployable on any IL4/IL5 cloud environment (e.g., AWS GovCloud, Azure Government).
• Oracle Database: DFAS is open to migrating to a cloud-native Oracle database, provided the functionality is converted like-for-like.
• Interface Documentation: Interface specifications for the 14 external systems will be provided to the selected vendor post-award.
• RMF/ATO: The vendor will collaborate with the SCRT Information System Security Manager to document security controls and ensure compliance. DFAS has not identified a specific E-ICAM endpoint or integration method.
• Place of Performance: Remote work is allowed, but some travel (up to one week per month) may be required. All development must be on Government Furnished Equipment and within the DoW network.
• UI Modernization: The refreshed UI should remain visually similar to the existing application, with exceptions for native user interface controls/objects of the target technology.
• ROM Pricing: DFAS prefers ROM estimates at both the RFI and RFP stages.
• Staffing: At a minimum, the government expects software developers, a project manager, and an analyst.
• New Requirement: This is a new requirement.

Key details such as the prohibition of low-code platforms, the need for full object refreshment, and the preservation of the existing module structure provide critical guidance for vendors developing proposals. The clarification on remote work and travel expectations is also important for resource planning. The absence of an incumbent and the status as a new requirement indicate a competitive landscape. The lack of defined timelines or specific contract vehicles suggests these will be determined based on market research and vendor responses.

Other / Unclassified (Sources Sought Notice)

This Sources Sought Notice (SSN) is issued by the Defense Finance and Accounting Service (DFAS) to gather market information on capabilities and solutions for a technical refresh of the Standard Contract Reconciliation Tool (SCRT). The SCRT is a legacy PowerBuilder application that automates and streamlines the contract reconciliation process. The primary drivers for this refresh are a strategic migration to cloud-native solutions, enhanced security to meet current DoD mandates, and future adaptability for easier integration of new processes and data.

• System Description: The current SCRT is a client-server application using PowerBuilder and an Oracle database, featuring modules for Registration, Compare, Adjustments, and Reports.

• Functional Requirements: The refreshed solution must achieve "like-for-like" functional parity with the current application, preserving core business value and user experience. It must maintain current usability with similar screen layouts and data entry fields.

• Technical Requirements: The new system must be built on a sustainable, secure, and extensible technology stack using a non-proprietary, object-oriented codebase (low-code/no-code platforms are prohibited). It must integrate with the existing Oracle 19c database and leverage existing database functionality. A robust DevSecOps pipeline is required, including GitLab for source control, Fortify (or equivalent) for static code analysis, and an automated test suite.

• Security and Compliance: The solution must comply with all applicable DoD and DFAS cybersecurity mandates, including Zero Trust Architecture, DISA STIGs, NIST publications, DoD RMF, and ICAM with CAC/PKI authentication. Vulnerability management, supply chain security, and handling of Controlled Unclassified Information (CUI) are critical.

• Performance and Stability: The refreshed system must meet or exceed the performance and reliability of the current application, aiming for at least 99.5% uptime annually. Data integrity and quality must be maintained.

• Response Format: Interested parties should submit a capability statement of no more than eight (8) pages.

• Content Requirements: The capability statement should include a description of the proposed solution (technology stack, technical approach, security, compliance), a project plan with timeline, cost breakdown, recent relevant contracts, dollar value, period of performance, point of contact, and scope of work.

• Specific Questions: Vendors must address specific questions regarding PowerBuilder experience, technical refresh approach, proposed technology stack, DoD security and ICAM integration, capabilities alignment, technical details, system interfaces, assumptions, disaster recovery, timeline, training/support, and ROM pricing.

• Eligibility: All qualified sources, including small businesses (8(a), service-disabled veteran-owned, HUBZone, women-owned), are encouraged to respond.

• Questions Due: March 23, 2026, at 12 PM ET

• Responses Due: March 31, 2026, at 12 PM ET

• This is a market research request, not a solicitation. Information received will not be disclosed outside the government.

• The government will grant unlimited rights in the resulting source code and functional application.