Appendix C
Appendix C — Budget-to-Disbursement Systems
Budget formulation, fund distribution, procure-to-pay, entitlement, and disbursing systems, and how they connect back to Sections 7 and 9.
Every system in Sections 1–11 of this paper is a general ledger or accounting system of record — GFEBS, DEAMS, DAI, and the rest. None of them are the first system a dollar touches. Before a dollar ever reaches a GL, it passes through a distinct layer of systems that formulate the budget request, distribute the resulting appropriation down through the department, and process the actual payment once an obligation is ready to be paid. These systems are not accounting systems by function — most contain no general ledger and post no USSGL entries directly — but they are structurally essential to the fund-management mission, and several of the audit and traceability issues this paper documents in detail (Sections 3.13, 9.6, 9.8–9.9) originate at the handoff points between this layer and the GL layer, not inside the GL systems themselves.
This annex organizes them into three functional layers, matching the order money actually moves: budget formulation and investment reporting (C.2), fund distribution (C.3), and procure-to-pay/entitlement/disbursing (C.4).
C.2 Budget formulation and IT investment reporting
| System | Owner | What it actually does |
|---|---|---|
| SNaP-IT (Select and Native Programming Data Input System for Information Technology) | DoD CIO | Not a GL system — an IT-investment budget reporting tool. SNaP-IT is used to publish the DoD IT Budget Estimates to Congress, the OMB Circular A-11 Section 53 and Section 300 exhibits, and monthly IT performance data to the OMB IT Dashboard. It works alongside the Defense Information Technology Portfolio Repository (DITPR, the inventory of DoD IT systems) through a shared registration front end (DITIP), so that every IT investment reported for budget purposes is also tied to a registered system record — conceptually the IT-budget analogue of the SFIS/Trading-Partner tagging problem this paper documents for financial transactions in Sections 5 and 7.6. |
| CAPE (Office of Cost Assessment and Program Evaluation) | OSD, reporting to the Secretary | Not a system — an analytical office, included here because it is frequently confused with one. CAPE produces independent cost estimates and program evaluations under the Weapon Systems Acquisition Reform Act of 2009 and oversees DoD-wide SNaP-IT data collection; it does not operate a GL or budget-execution system itself. |
| PBES (Program & Budget Enterprise System) | Air Force (Department of the Air Force) | The Air Force's current Planning, Programming, Budgeting, and Execution (PPBE) budget-formulation system, fully deployed in December 2021. PBES replaced four legacy Air Force PPBE systems in a single consolidation: ABIDES, RAPIDS, FSDM, and ETT — a budget-formulation-layer parallel to the accounting-layer consolidation GAFS-R/DEAMS represents (Sections 3.4, 3.15). PBES supports program budget and resource-allocation decisions and Congressional budget-justification reporting; it does not post to a GL. |
| NGRMS (Next Generation Resource Management System) | OUSD(Comptroller), jointly with CAPE | The Department's flagship OSD-level system used to formulate, justify, present, and defend the entire DoD budget — documented in DoD budget-justification materials continuously since at least FY2012. NGRMS is explicitly designed to replace and consolidate multiple older, redundant OSD-level budget formulation/programming databases into a single, unified data source shared by OUSD(C) and CAPE, run on a milCloud environment with Production, Development, and Continuity-of-Operations instances. Per DoD's FY2026 PPBE Reform Activities report, NGRMS President's Budget data now flows directly into an Advana SIPR (classified) enclave, and the PPBE Reform Commission's 2023–2024 recommendations specifically cite “leveraging the NGRMS for data management” as part of the Department's broader effort to rationalize its OSD-level resourcing systems. |
| PROBE (Program Optimization and Budget Execution System) | Army | The Army's system for documenting its position through the Planning, Programming, Budgeting, and Execution process — the Army's own named budget-formulation/execution data-management system, analogous in function to the Air Force's PBES/ABIDES lineage and the Navy's PBIS below. |
| PBIS (Program Budget Information System) | Navy, jointly owned/administered by OPNAV (N80, Programming Division, is the official Program Manager) and ASN(FM&C) | The Navy's single, official repository for program and budget estimates — the system of record used to develop and submit the Department of the Navy's long-range financial plan (the Program Objective Memorandum) and budget to OSD, and subsequently to allocate appropriated funds and monitor execution. PBIS runs on an Oracle database accessed through a web front end, operates on both the unclassified and classified Navy Marine Corps Intranet, and consists of an unclassified server complex hosted in AWS GovCloud plus a separate classified server complex. As of its most recent public sustainment-contract description, PBIS had over 3,000 active user accounts, roughly 20% at the Pentagon and the remainder across Navy and Marine Corps commands worldwide; a subsystem, PBISweb, extends the same function to web-based users. |
| CIS (Comptroller Information System), PRCP, SDCS | OSD-level, receiving submissions from the Services | OSD-level data-collection systems that Service budget-formulation systems (e.g., Air Force's ABIDES/PBES) submit budget database exhibits into — CIS, the Program Resource Collection Program (PRCP), and the Standard Data Collection System (SDCS) are named together in Air Force budget-office contract documentation as the OSD-side receiving systems for Service exhibit submissions. This paper can confirm these three systems exist and receive Service submissions, but found materially less public documentation on CIS specifically than on NGRMS, PBIS, or PROBE — treat the level of technical detail here as correspondingly lighter. |
| RMT (Resource Management Tool) | Cross-DoD | Described in Service PPBE training material as a “one-stop shop” portal bringing together the data needed to perform financial-management functions across the PPBE process; this paper located it named as a cross-cutting PPBE productivity tool but could not confirm its owning organization or technical architecture with the same confidence as the systems above. |
A note on sourcing for this table: several system names in this table were checked directly against an external list a person had compiled from a separate source. Of the names checked, NGRMS, PBIS, PROBE, ABIDES, PBES, CIS, PRCP, and SDCS were all independently confirmed against DoD budget-justification documents, contract descriptions, or academic/training sources. Several other names from that same external list — an “Exhibit Automation System (EAS),” an Army “Automated Budget Formulation (ABF)” system, “cARMY,” an Air Force “ABES,” and a “Budget Data Management System (BDMS)” for Defense Agencies — could not be confirmed against any public source in this research pass and are deliberately omitted from this table rather than included on the strength of an unverified external claim. This is a direct application of this paper's standing practice throughout: verify before asserting, and flag rather than guess when verification fails.
C.3 Fund distribution: getting apportioned budget authority down to the level that can obligate it
| System | What it actually does |
|---|---|
| PBAS (Program Budget Accounting System) | A DoD-wide system used to control and distribute funds from the department level down to DFAS field sites — the mechanical layer between OMB's apportionment of an appropriation and a Component's ability to obligate it. PBAS creates funding documents and transmits receipts electronically, and its system controls are specifically designed to prevent over-distribution: it limits the amount distributed to what the appropriation sponsor loaded into PBAS, and separately enforces the dollar thresholds Congress sets for reprogramming actions. PBAS currently distributes funds apportioned to the Army, Air Force construction funds, civil works funds, and OSD/Defense Agency allocations. A Reserve-Component-specific web variant, PBASweb, performs the equivalent function for the Air Force Reserve Command's Reserve Personnel Appropriation. |
| EFD / EFDSS (Enterprise Funds Distribution System Support) | Correction from this paper's earlier draft, which mis-expanded this as “Electronic Funds Distribution” — the correct name, per DoD's own OSD budget-justification materials going back over a decade, is Enterprise Funds Distribution, owned by OUSD(Comptroller). EFDSS is OUSD(C)'s automated system for controlling and distributing funds — covering apportionment, reprogramming, rescissions, and continuing-resolution funding levels. This paper's earlier research on DAI's program documentation (Section 3.6) separately found EFD explicitly named as needing “an automated real time Financial Accounting Document (FAD) interface to DAI,” with mapping required for differences in how general ledger postings are created between the two systems — confirming EFD is the fund-distribution-layer counterpart to PBAS for the Defense Agencies specifically, feeding DAI the way PBAS feeds the Military Departments' systems. |
PBAS and EFD are the direct answer to “how does an apportionment actually turn into a budget position a unit can obligate against” (Section A.4's first row, “budget position”) — this paper's Section 7 use cases all begin at the moment funds are already distributed to the executing unit; PBAS/EFD are what makes that distribution happen mechanically, upstream of every use case this paper traces.
C.4 Procure-to-pay, entitlement, and disbursing: the systems between a receiving report and a bank transfer
Section 9.3 already traced GFEBS's own internal MIRO/FB60/F110 transaction codes for this stage. What that section didn't cover is that outside a fully integrated ERP (GFEBS, Navy ERP, DEAMS, DAI all handle this internally), a large share of DoD's contract payments physically route through a shared, Component-agnostic front end — PIEE/WAWF — before being handed off to whichever Component-specific “entitlement system” actually computes and certifies the payment. This is genuinely a distinct architectural layer from anything else in this paper, and it is worth mapping precisely:
| Layer | System | Function |
|---|---|---|
| Shared front end | PIEE (Procurement Integrated Enterprise Environment), historically known by the name of its core module, WAWF (Wide Area Workflow) | A single, DoD-wide, Web-based portal where a vendor submits an invoice and a government official submits receipt/acceptance — combining the contract, the invoice, and the receiving report into one “virtual folder” before forwarding the matched package to the correct Component entitlement system. WAWF is the only acceptable electronic system for submitting DoD contract payment requests, per DFARS 252.232-7003 implementing Section 1008 of the FY2001 NDAA. Vendors track their own invoice status through PIEE's myInvoice module. |
| Supporting/cross-reference systems within PIEE | EDA (Electronic Data/Document Access), CEDMS (Corporate Electronic Document Management System), SAM (System for Award Management) | EDA is where an entitlement system or COR verifies the contract actually on file matches what's being invoiced (a common source of an invoice sitting in “suspense” status is the contract simply not yet being in EDA); SAM is where vendor registration and remittance/banking data is verified before any payment can be certified. |
| Entitlement system: Army, Defense Agencies, USMC | CAPS-W (Computerized Accounts Payable System – Windows) | Receives the matched PIEE package and performs the entitlement/computation function — reviewing contract, invoice, and receiving report for propriety, verifying vendor SAM registration and remittance data, and computing the amount actually owed — before certifying it for payment. |
| Entitlement system: Air Force | IAPS-E (Integrated Accounts Payable System – Electronic) | The Air Force's equivalent entitlement/accounts-payable computation system, performing the same function CAPS-W performs for the Army/Defense Agencies/USMC. |
| Entitlement system: DLA | EBS (the same DLA Enterprise Business System profiled in Section 3.7), formerly called BSM | DLA's own SAP-based ERP performs its own entitlement computation internally rather than routing to a separate standalone entitlement system — consistent with Section 3.7's description of EBS as DLA's integrated supply-chain-to-financial system. |
| Entitlement system: Navy, Defense Agencies, USMC (a second option alongside CAPS-W) | One Pay | A Navy-family entitlement/commercial-payment system; per Section 3.3's STARS-family profile, One Pay is the modern successor to STARS-One Pay, DFAS's legacy Navy commercial-entitlement processing capability. |
| Entitlement system: all Military Services, contract administration specifically | MOCAS (Mechanization of Contract Administration Services) | Operated for the Defense Contract Management Agency (DCMA) and used by all Military Services for contract administration-related entitlement processing — a specialized, DCMA-centered entitlement path distinct from the general commercial-invoice path CAPS-W/IAPS-E/One Pay handle. |
| Direct-integrated (no separate entitlement system) | Navy ERP, GFEBS, DEAMS, DAI | These four ERPs, already profiled in depth in Sections 3.1–3.2 and 3.4 and 3.6, receive WAWF/PIEE data directly rather than routing through a separate standalone entitlement system — the entitlement/AP computation function (MIRO/FB60 in GFEBS's specific case, per Section 9.3) happens natively inside the ERP itself. |
| Disbursement | ADS (Automated Disbursing System) | Once an entitlement system (or an ERP's native AP module) certifies a payment is due, ADS is the DFAS-operated system that actually executes the disbursement instruction and reports it to Treasury — the system this paper's Section 9.6 identified as sitting downstream of GFEBS's F110 payment run. ADS is DFAS's centralized disbursing capability, used across Components rather than being Component-specific, consistent with DFAS's broader role (Section 3, Annex B) as the department's consolidated disbursing and accounting service provider. |
A note on “CAPS” without the “-W”: some DFAS materials refer simply to “CAPS” as the Army/Defense-Agency/USMC entitlement system; “CAPS-W” (the Windows-based iteration) is the currently operative name in DFAS's own vendor-facing documentation and is used consistently in this annex. Treat the two names as referring to the same system lineage rather than two different systems.
C.5 How this layer connects back to Sections 7 and 9
This annex's systems slot into the ten-stage backbone from Section 7 at two specific points that this paper's earlier sections described in general terms without naming the intermediate systems explicitly:
- Between “Authority received” and “Commitment” (Section 9.2, stage 1–2): PBAS and EFD are the actual mechanism, not merely a conceptual budget position — an apportionment does not become obligatable budget authority at a unit until PBAS (for Military Department/civil works/OSD funds) or EFD (for DAI/Defense Agency funds) has electronically distributed it.
- Between “Accrued expenditure” and “Expense/Disbursement” (Section 9.2, stages 4–6, and Section 7.2's contract use case): for any contract payment that isn't processed natively inside GFEBS, Navy ERP, DEAMS, or DAI, the actual path runs PIEE/WAWF → the applicable entitlement system (CAPS-W, IAPS-E, One Pay, or MOCAS) → ADS → Treasury, a three-system relay this paper's Section 7.2 and Section 9.3 previously described only at the ERP-internal level (MIRO/FB60/F110).
Practically, this means a transaction traceability question of the kind Section 9.9 walks through for GAFS/ABSS has a PIEE-side analogue: if a payment is delayed or a receiving-report/invoice mismatch occurs, EDA (is the contract on file?) and the specific entitlement system's own suspense-status logic are the first places to look — upstream of, and structurally distinct from, anything inside the GL system itself.
C.6 Terms this paper could not confirm
Update: NGRMS and PBIS, both originally flagged as unconfirmed in this annex's first draft, were subsequently verified against multiple independent DoD sources and are now fully profiled in Section C.2 above — that was a research gap in the earlier pass, not evidence the systems don't exist, and both are now sourced with the same confidence as the rest of this paper. What remains genuinely unconfirmed, after a dedicated verification pass against an external list that proposed specific expansions: an “Exhibit Automation System (EAS),” an Army “Automated Budget Formulation (ABF)” system (the real, confirmed Army system is PROBE, per Section C.2), “cARMY,” an Air Force “ABES” distinct from PBES/ABIDES, and a Defense-Agency-wide “Budget Data Management System (BDMS).” None of these were matched to a specific, currently-documented DoD system in this research pass, despite a dedicated search attempt for each. The same caveat from Section 9.6 applies to “DDS”: it remains unmatched to a specific documented system name across this entire paper's research.
ANNEX D
Inside DDRS: Business Rules, Journal Vouchers, and How Much Actually Changes Between GL and Financial Statement
Sourced to DFAS's own “Standard Finance and Accounting Requirements” library, the DoD Financial Management Regulation chapter that actually governs DDRS journal vouchers, and a decade-plus of DoD IG/GAO audits that tested the process directly.