The Full Transaction Lifecycle

Every prior section of this paper describes systems as static boxes. This section instead follows a single dollar as it moves through the department's accounting architecture end to end — written so a new employee, on their first day, can follow every step without needing outside context. Each use case below states its trigger, walks a day-by-day timeline through the systems and interfaces involved, and shows exactly how a business event becomes a budget position, then a journal voucher, then a general ledger posting, then a trial balance, then cash movement, and finally a line on an audited financial statement.

7.0 Glossary — read this first if any of the following terms are new

The ten-stage backbone shown in the diagram above and detailed timelines below is summarized here for quick reference:

A methodological caveat that applies to every use case below: exact SAP transaction codes (T-codes), Oracle EBS form/responsibility names, and specific table names are Component-configured and are not published in unclassified open sources for GFEBS, Navy ERP, DEAMS, or DAI (see Section 6). Where this section cites a T-code or table name, it is the standard, unmodified SAP ECC or Oracle EBS out-of-the-box object that the DoD Component's configuration is documented to be built on — offered as a representative illustration, not a verified screenshot of a live configuration. USSGL account numbers are public (published by Treasury/OUSD(Comptroller)) and are cited with higher confidence; where a specific sub-account within a USSGL account series is genuinely uncertain, this section says “a 4200-series account” rather than guessing a precise four-digit code.

7.1 Use case 1 — Travel (Temporary Duty, TDY)

Trigger: an approving official signs Temporary Duty (TDY) orders for an employee to attend training or perform official travel.

Where it lands: the Statement of Net Cost (as travel expense) and, if unpaid at year-end, the Balance Sheet (as Accounts Payable). Audit focus: completeness of accrued-but-unfiled travel claims at cutoff, and the DTS-to-ERP interface reconciliation itself.

7.2 Use case 2 — Contract (Procure-to-Pay)

Trigger: a Contracting Officer executes (signs) a firm-fixed-price contract for spare parts.

Where it lands: Balance Sheet (Accounts Payable, and Inventory or General PP&E if the item was capitalized) and Statement of Budgetary Resources. Audit focus: existence of the three-way match, and completeness of accrued unbilled/unmatched liabilities at period end — a chronic, long-documented DoD weakness.

7.3 Use case 3 — Inventory

Trigger: a shipment of aircraft repair parts arrives at a DLA wholesale distribution depot against an existing contract.

Where it lands: Balance Sheet (Inventory / Operating Materials & Supplies) and, on issue, the Statement of Net Cost. Audit focus: existence and completeness via statistical sampling and physical test counts at depots — DoD's single most storied audit challenge in this category — plus valuation and rights (does DoD actually own it, versus holding it for another agency or an FMS customer).

7.4 Use case 4 — Property (Real Property / General PP&E)

Trigger: a military construction (MILCON) contract for a new barracks building is awarded and construction begins.

Where it lands: Balance Sheet (General PP&E, net of accumulated depreciation) and, going forward, the Statement of Net Cost (depreciation expense). Audit focus: existence and completeness of the real-property inventory (does every RPUID correspond to a facility that actually exists, and vice versa), valuation of older facilities whose original cost had to be estimated, and whether assets sit in Construction-in-Progress long after they are actually in service.

7.5 Use case 5 — Lease (Right-of-Use accounting under SFFAS 54)

Trigger: a Component executes a multi-year lease for warehouse space from a commercial landlord.

SFFAS 54 implementation is recent enough (FY2024 first full year) that Component-specific DoD IG or GAO findings on execution quality were still emerging as of this paper's research; treat the discount-rate and USSGL-account specifics above as the standard's conceptual model, and verify current Component-specific implementation detail before relying on it for an official product.

Where it lands: Balance Sheet (a new ROU asset and lease liability that, for most of DoD's history, simply didn't exist — operating leases were previously expensed as incurred). Audit focus: completeness of the lease population first (did the Component identify every lease it holds, including informal or embedded leases inside larger service contracts — DoD historically had no single lease inventory), then valuation (correct discount rate and payment stream) and recalculation of the amortization schedule.

7.6 Use case 6 — Intragovernmental Transactions (IGT): central order-taking, DoD MIPRs, and other-agency purchases

IGT is different from the first five use cases in one crucial respect: both sides of the transaction are the federal government. When the Army buys spare parts from Lockheed Martin, the government's balance sheet grows by an asset paid for from outside the government. When the Army buys engine repair work from a Navy depot, no new money enters the government at all — it simply moves from one federal ledger to another, and if either side books it wrong, the government's consolidated financial statements can double-count or miss the transaction entirely. That risk — intragovernmental elimination and reconciliation — has been one of GAO's standing impediments to a government-wide clean opinion for decades, which is why IGT gets its own use case with three sub-processes.

7.6.1 Sub-process A — Central order-taking: the G-Invoicing General Terms and Conditions (GT&C) and Order

Trigger: any two federal trading partners (DoD-to-DoD, DoD-to-other-agency, or other-agency-to-DoD) need to buy and sell goods or services from each other. Since Treasury's Bureau of the Fiscal Service made it mandatory (new agreements required to onboard starting October 2021, replacing the old manual SF-7600A/7600B “Economy Act order” paperwork), essentially every intragovernmental transaction — including the MIPR and other-agency sub-processes below — runs through this same central chassis first.

7.6.2 Sub-process B — DoD MIPR (Military Interdepartmental Purchase Request)

Trigger: a DoD “requiring activity” (say, an Army program office) needs work performed or supplies furnished by another DoD “performing activity” (say, a Navy shipyard, a DLA distribution center, or another Military Department's working-capital-fund activity) rather than by an outside contractor.

7.6.3 Sub-process C — Non-DoD other government agency (OGA) purchase

Trigger: a transaction crosses the boundary between DoD and a civilian federal agency — either DoD buying from an OGA (e.g., leasing space or vehicles from the General Services Administration, or purchasing background investigations from the Office of Personnel Management) or an OGA buying from DoD (e.g., the Department of State reimbursing Air Mobility Command for airlift support, or the Department of Homeland Security's Coast Guard — itself sometimes a DoD service under Title 10 in wartime — buying fuel through DLA Energy).

Where all three IGT sub-processes land: on the buying side, an expense (Statement of Net Cost) and, if unpaid, a Balance Sheet payable; on the selling side, exchange revenue and, if unbilled, a receivable. At the government-wide level, both sides should net to zero through GTAS elimination — audit focus across all three sub-processes is specifically whether they actually do net to zero (a documented, longstanding weak point), completeness of billing (did the seller actually invoice for everything it performed), and correct Federal/Non-Federal trading-partner tagging at the point of original GL posting, since that single data element is what allows DDRS and GTAS to even attempt the match.

7.7 Use case 7 — The F-35 Joint Strike Fighter (JSF) program: a major defense acquisition program crossing multiple systems of record

Trigger: a Lockheed Martin production lot delivers an F-35A airframe to the Air Force under a Low-Rate/Full-Rate Production contract; separately, a spare part is issued from the global sustainment supply chain to a squadron. The first six use cases each stayed inside one Component's one ERP (or, for IGT, a clean two-party exchange). The F-35 program is included specifically because it does not — and that is the point.

Where it lands — and the structural lesson: because JSF has no single system of record, it also has no single audited “JSF financial statement.” Air Force General Fund's independent auditor tests DEAMS-recorded F-35A balances as part of the Air Force General Fund audit; Navy General Fund's and Navy Working Capital Fund's auditors separately test Navy ERP-recorded F-35B/C balances. The closest thing to a consolidated JSF financial picture is GAO's annual Weapon Systems Assessment and the program's Selected Acquisition Report (SAR) — both programmatic cost-and-schedule reports, not audited financial statements, and neither runs through the DDRS/GTAS chain this paper describes. This is the clearest illustration in the entire paper of the point made in Section 2: DoD's financial architecture is organized around reporting entities, not programs — exactly the cross-system reconciliation problem CDAO's Advana platform (Section 5.3) exists to solve at the data layer, even though it doesn't change the underlying fact that no single general ledger owns the program.