In an era of real-time payments, cloud‑native software, and AI‑assisted reconciliations, it’s natural to wonder: Why hasn’t the federal government created API connections with contractor accounting systems?
The question, recently posed on LinkedIn, ignited a wave of industry responses. It is a “dumb” question only in the sense that it dares to challenge assumptions. From a technical standpoint, the answer should be simple, since APIs are everywhere. In the world of government compliance, “technically feasible” does not always mean “practically viable.”
In a recent conversation, Monica Reed, Finance & Compliance Portfolio Executive, and Jason Merrell, Senior Systems & Integration Engineer, unpacked this issue from their own perspectives. What followed was a clear‑eyed breakdown of the friction points that prevent seamless integrations between government systems and contractor platforms. The result of this candid conversation are five reasons why these two systems cannot talk to each other, at least for right now.
1. Oversight Trumps Optimization
To get right to it, the federal government is not in the business of making anyone’s ERP more efficient. It is in the business of making sure taxpayer dollars are accounted for, down to the penny, and that every transaction can survive an audit.
Internal controls drive architecture. OMB Circular A‑123 makes agency leadership responsible for internal control and risk management. That incentive structure favors traceability over convenience.
Security controls bound the interfaces. NIST SP 800‑53 requires rigorous access control, audit logging, and monitoring, so any live data pipe is a controlled interface, not a casual connection.
Reporting is standardized by rule. FAR 52.216‑7 requires annual incurred‑cost submissions, and DCAA’s ICE model prescribes how to package the data. That is a reporting pipeline by design, not a two‑way sync.
As Jason quips in the video, “Excel and email are the government’s API.” The point is not sarcasm. It’s survival.
2. Contracts Are Moving Targets
APIs thrive on stable schemas. However, federal contracts do not always play nice.
FAR Part 16 permits a wide range of contract types, and real programs evolve through modifications under FAR Part 43. Task orders can begin as firm‑fixed‑price, add time‑and‑materials CLINs, then layer in incentives or changes in performance scope. Encoding those judgment calls into a single interface is brittle.
Monica and Jason underscore this reality: much of the work is interpretation of numbers against evolving contract language. That is normal, not a corner case.
3. System Incompatibility Is the Default
There is no single federal accounting platform to plug into. Large agencies run different ERPs and are modernizing on different timelines.
Examples across the Department of Defense include:
Air Force: DEAMS, a COTS‑based ERP supporting thousands of users, managed by the Office of the Director, Operational Test and Evaluation (DOTE).
Navy: Navy ERP, the Department of the Navy’s financial system of record, now moving toward “ERP+” modernization.
Army: GFEBS, an SAP‑based system for general fund operations.
The Government Accountability Office (GAO) continues to flag legacy IT and fragmented modernization as government‑wide constraints, hardly an API‑friendly landscape. While legacy systems ranging anywhere from 8 to 51 years old provide vital support to their missions, operation and maintenance collectively cost around $337 million.
In practice, contractors meet portals, not open endpoints. Invoices route through DoD’s PIEE/WAWF and Treasury’s IPP, which are controlled submission systems designed for validation, workflow, and security, not system‑to‑system writes.
4. Certification Requirements Are Daunting
Even if an API is technically simple, the compliance runway is long and bumpy.
FedRAMP governs cloud services. Authorization requires sponsorship and continuous monitoring. New interconnections can change the authorization boundary and trigger additional review.
Defense contracts bring CUI obligations. DFARS 252.204‑7012 requires safeguarding Covered Defense Information and incident reporting, and it references NIST SP 800‑171 for protecting CUI in nonfederal systems.
OMB A‑130 adds lifecycle governance. Agencies must manage information, privacy, and security across data lifecycles, which raises the bar on interconnections. As Jason puts it, feasible does not mean approvable, and certification is slow and risk‑averse.
5. The Playing Field Must Remain Level
If APIs were the norm, who would benefit first? It would most likely be the well‑capitalized primes with in‑house compliance and DevSecOps. Uniform submissions and centralized portals remain the leveling mechanism for small businesses.
Policy reflects that choice. Treasury standardized spending data through the DATA Act Information Model Schema, now rebranded as the Governmentwide Spending Data Model (GSDM), to improve reporting quality without mandating operational accounting APIs for every vendor.
APIs Aren’t the Endgame, Trust Is
The government is not anti‑automation. It is pro‑verifiability. What matters is the ability to explain data, allocations, labor mapping, rate development, and controls from start to finish. If your systems produce clean ICE schedules, structured cost narratives, and transparent invoice logs, you do not need an API to be credible.
Sources & Further Reading
OMB Circular A-123 – Management’s Responsibility for Enterprise Risk Management and Internal Control (Office of Management and Budget), https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2016/a123.pdf
NIST SP 800-53 Rev. 5 – Security and Privacy Controls for Information Systems and Organizations (National Institute of Standards and Technology), https://csrc.nist.gov/pubs/sp/800/53/r5/final
FAR 52.216-7 – Allowable Cost and Payment (Federal Acquisition Regulation), https://www.acquisition.gov/far/part-52#FAR_52_216_7
DCAA Incurred Cost Electronically (ICE) Model (Defense Contract Audit Agency), https://www.dcaa.mil/ice/
FAR Part 16 – Types of Contracts, https://www.acquisition.gov/far/part-16
FAR Part 43 – Contract Modifications, https://www.acquisition.gov/far/part-43
Air Force DEAMS – Defense Enterprise Accounting and Management System (DOT&E FY2024 Annual Report), https://www.dote.osd.mil/Portals/97/pub/reports/FY2024/af/2024deams.pdf
Navy ERP – Navy ERP+ Modernization Program (U.S. Navy), https://www.doncio.navy.mil/CHIPS/ArticleDetails.aspx?ID=15571
Army GFEBS – General Fund Enterprise Business System (U.S. Army), https://www.gfebs.army.mil/
PIEE/WAWF – Procurement Integrated Enterprise Environment (Wide Area Workflow) (DoD), https://piee.eb.mil/piee-landing/
Treasury Invoice Processing Platform (IPP) – Bureau of the Fiscal Service, https://www.ipp.gov/
FedRAMP – Program Overview and Authorization Process (General Services Administration), https://www.fedramp.gov/program-basics/
DFARS 252.204-7012 – Safeguarding Covered Defense Information and Cyber Incident Reporting, https://www.acquisition.gov/dfars/252.204-7012
NIST SP 800-171 Rev. 2 – Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, https://csrc.nist.gov/pubs/sp/800/171/r2/final
OMB Circular A-130 – Managing Information as a Strategic Resource, https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf
Governmentwide Spending Data Model (GSDM) – U.S. Department of the Treasury, https://www.fiscal.treasury.gov/data-transparency/gsdm.html
GAO High-Risk Report 2025 – Critical Actions Needed to Address IT Acquisition and Management Challenges, https://www.gao.gov/highrisk/information-technology-acquisitions-and-operations
GAO Report – Agencies Need to Continue Addressing Aging Legacy Systems (GAO-23-106810), https://www.gao.gov/products/gao-23-106810
