E-Invoicing in the United States

Market-driven approach with federal mandate through IPP platform

Select a country

Overview

The United States has no national mandatory e-invoicing system, and the structural reason is worth stating first: there is no federal VAT or GST. Without a federal input-and-output tax to police, there is no tax authority that needs to see or approve invoices. The IRS is not part of invoice exchange, there is no clearance, no continuous transaction control and no real-time reporting.

What exists instead is procurement obligation at federal level — real, contractual and often strict — and a voluntary industry network, DBNAlliance, built on a Peppol-like four-corner model. Neither is a tax system. Treating the US as "a country with no e-invoicing" is as wrong as treating it as one with a mandate.

EAS 9959

the EIN — a federal business identifier, and emphatically not a VAT number

UBL 2.3

the DBNAlliance network format — not UBL 2.1 and not EN 16931

3 years+

the base IRS period of limitations, with longer periods in defined cases

Timeline

The American dates are about federal procurement and voluntary infrastructure. There is no tax mandate roadmap to track — and no announced date for one.

Already in force

17 July 2015

OMB Memorandum M-15-19

The Office of Management and Budget directs federal agencies to move to electronic invoicing for appropriate federal procurements by the end of fiscal year 2018, defining an e-invoice as structured data moving through an electronic workflow with minimal manual intervention.

End of FY 2018

The agency transition deadline

The date by which agencies were to have made the move. Note this bound the agencies, not every supplier — see Federal B2G.

Summer 2023 onward

The exchange framework goes live

The Business Payments Coalition market pilot becomes the DBNAlliance exchange framework — the first nationwide standardised e-invoice exchange network in the US, and entirely voluntary.

Still ahead

1 July 2030

ViDA — in the EU, relevant to US groups only through EU operations

Nothing in ViDA obliges a US company as such. See Cross-border and ViDA.

Saying "B2G e-invoicing has been mandatory in the US since 2018" is too broad. Federal agencies were required to move to electronic processing of appropriate procurements by the end of FY 2018 — but the channel a supplier must use is set by the individual contract, the FAR and DFARS, the agency supplement and the solicitation. There is no single federal format or portal.

Why there is no clearance

This is the structural point that makes the US different in kind rather than in degree. At federal level there is no general VAT or GST. The IRS administers corporate and individual income taxes, employment and self-employment taxes, excise taxes, withholding and others. Sales taxes are imposed mainly by states and local governments, each administering its own regime.

With no federal input-and-output tax mechanism, there is no federal reason for a tax authority to receive or approve each invoice. So for ordinary B2B and B2C transactions:

Centralised clearanceNo

Invoice sent to the IRS before the buyerNo

A government unique invoice IDNo

A government digital signature on the invoiceNo

A tax authority five-corner modelNo

Invoice-level real-time reportingNo

A mandatory government validation schemaNo

The federal B2G platforms do not change this. IPP and WAWF are procurement, approval, receiving and payment workflow systems — not tax clearance systems. They exist to get a government agency to pay a vendor correctly, not to validate a commercial invoice for tax purposes. The American model is post-audit recordkeeping, not pre-authorisation.

Federal B2G — IPP and WAWF

Federal B2G in the US is not one centralised system but a set of agency-level decisions. In practice a supplier will meet one of:

IPPThe Treasury's Invoice Processing Platform, used by many civilian agencies. The platform reports over 220 federal agencies, more than 200,000 vendors and over $122 billion in invoice value — and it is provided at no charge to agencies and vendors alike

WAWFWide Area WorkFlow, for the Department of Defense

Agency systemsIndividual ERP portals and departmental platforms

EmailIn some contracts, PDF or TIFF by email

PaperIn exceptional cases

How strict this gets

Individual agencies are considerably firmer than the general picture suggests. Treasury contracts require payment requests through IPP unless the Contracting Officer has authorised an alternative in writing. The EPA requires IPP and states expressly that email with a scanned document is not itself an electronic form of payment request.

The Department of Defense is stricter still

DFARS 252.232-7003 requires contractors to submit payment requests and receiving reports electronically through WAWF, with limited exceptions. Permitted methods are EDI, secure file transfer, or direct entry through the WAWF web interface — and the DFARS states separately that fax, email and scanned documents are not an acceptable electronic form of the primary payment request. They may only accompany it as supporting documentation.

Note what this obligation rests on: federal procurement law and contract terms, not tax law. That is why it can be simultaneously true that the US has no e-invoicing mandate and that a defence contractor has no choice about how it invoices.

States and municipalities

There is no federal deadline reaching the procurement of all states, counties, cities and other local bodies. Public buyers below federal level run their own supplier portals, ERP systems, EDI arrangements, email processes or paper workflows.

Before onboarding a supplier for public sector work, five things need checking every time:

The procurement rules of the specific state or municipality

The terms of the solicitation and the contract

Registration in the relevant vendor portal

The mandatory supplier ID, purchase order number and routing codes

Which invoice submission methods are actually permitted

This is unglamorous work, and it is the real cost of the American public sector. There is no national directory that answers these questions.

B2B and B2C

No federal law or approved timetable requires US companies to issue B2B invoices electronically, to use structured XML, to transmit invoices through a government platform, to pre-register an invoice with the IRS, or to report transaction data in real time. No mandatory date has been announced.

DBNAlliance itself describes the US market as fragmented and notes the absence of common infrastructure comparable to Peppol in parts of Europe and Asia. Its network is positioned as voluntary standardisation of B2B exchange, not as a government system.

B2C

No federal mandate either. A business may issue a paper receipt or invoice, a PDF by email, an electronic receipt, a document in a customer portal, structured data, or anything else permitted by applicable federal and state law. The federal E-SIGN Act provides that a contract, signature or record cannot be denied legal effect solely because it is electronic — while specific consumer protection requirements on notice content and on the ability to retain and reproduce the document continue to apply.

The DBNAlliance network

The Digital Business Networks Alliance grew out of the Business Payments Coalition market pilot and now governs the US exchange framework. Architecturally it will look familiar to anyone who knows Peppol — and the differences matter more than the similarities.

Familiar architecture

A four-corner model — supplier, supplier Access Point, buyer Access Point, buyer — using AS4, SML and SMP, digital certificates and dynamic discovery of the recipient and its capabilities.

Different substance

No tax fifth corner, no obligation to copy any invoice to the IRS or a state tax authority, and no government Peppol Authority. Industry-led and voluntary throughout.

Two things to keep straight. The network format is OASIS UBL 2.3 for the Core Invoice and Credit Note — not UBL 2.1, not EN 16931. And DBNAlliance is not the US Peppol Authority: it is a separate network with its own rules, certificates, SML and SMP, and its own accreditation. A Peppol certificate does not carry across.

Formats and PDF

US federal law does not require EN 16931, a Core Invoice Usage Specification, Peppol BIS Billing 3.0, UBL 2.1, UN/CEFACT CII, Factur-X or ZUGFeRD. Government solutions use their own data models, procurement forms, EDI implementation guides and web forms.

IPPWeb entry, PO flip, batch invoice files, ERP integration, attachments, approval and payment statuses. Automated integration uses EDI 810 and EDI 210 over SecureTransport, converted internally to an eFile XML. Purchase orders can go out as EDI 850, XML or CSV

WAWFDirect web entry, EDI, and SFTP or file transfer, with document types including Invoice, Invoice 2-in-1, Combo, Receiving Report, Cost Voucher and Progress Payment. The mandatory object is the data, not a PDF file

DBNAllianceOASIS UBL 2.3 between Access Points. A participant may exchange with its own provider in an ERP-native format, but the document crossing the network must follow the DBNAlliance rules

A point that catches integrators out

IPP and WAWF are separate systems and are not being merged. IPP states that invoices under most DoD contracts are processed through WAWF and that there are no plans to combine the two platforms. Build for both, or scope to one deliberately.

Where the PDF sits

A PDF is legally usable for commercial documents where it meets the contract and applicable law — the E-SIGN Act recognises electronic records provided they can be retained and accurately reproduced. But its status depends entirely on the process:

—The Department of Labor accepts electronic invoices in PDF or TIFF, and in some cases receipt by email

—HUD has contracts under which invoices are sent by email

—The DoD does not recognise PDF, a scan or email as an electronic form of the primary payment request in WAWF

—The EPA accepts a scanned document only as an attachment to a structured IPP submission

So PDF is permitted, is not a universal structured e-invoice, and guarantees nothing about compliance with a specific B2G contract.

Identifiers

The current Peppol code list includes one US-specific scheme, alongside international ones that are technically usable depending on the specification and the participant's registration:

9959Employer Identification Number (EIN) — the federal business identifier used by the IRS to identify a business entity

0060D-U-N-S Number

0088Global Location Number / EAN Location Code

0209GS1 identification keys

The EIN is not a VAT ID, because there is no federal VAT — and a platform that treats the two as equivalent will produce nonsense in validation and in reporting. DBNAlliance likewise uses DUNS, GLN and US:EIN, with SML and SMP lookups carrying a scheme ID and participant ID that may be any of them. Do not assume one identifier type covers a US counterparty.

Peppol in the US

Peppol is not a mandatory federal channel, not a statutory B2B infrastructure, not required for public procurement, not a means of tax clearance and not a B2C channel. OpenPeppol publishes no separate country profile for the United States — although certified Access Points registered in the US do appear in the OpenPeppol list, so American organisations can participate technically without any national mandate.

No United States Peppol Authority

None has been published. Keep the two worlds distinct: the OpenPeppol network, governed by OpenPeppol agreements and the relevant authority or coordinating body; and DBNAlliance, a separate American industry network with its own rules, certificates, SML and SMP, and its own accreditation. DBNAlliance should not be described as the US Peppol Authority.

Requirements for providers

No federal Access Point licence comparable to the Slovak digitálny poštár exists for ordinary e-invoicing services to US B2B and B2C clients. A provider may offer invoice generation, ERP integration, EDI, PDF delivery, archiving, AP automation, Peppol connectivity and DBNAlliance connectivity, subject to ordinary contractual, privacy, cybersecurity, tax recordkeeping and sector requirements.

DBNAlliance certification is separate and real

Operating within DBNAlliance requires its own certification regardless of any Peppol certification, because these are different trust domains with different certificate authorities. The process runs:

—Membership and onboarding

—Registration in the SML, and obtaining digital certificates

—Using an own or shared SMP, and configuring AS4

—Interoperability testing — a two-month testing period

—Successful Core Invoice exchange with at least three certified service providers, and three confirmation letters

—Issue of a production certificate and Certified Service Provider status

Foreign providers

No general prohibition on a foreign e-invoicing provider serving US clients was identified in national law. Three practical routes exist:

Ordinary commercialSaaS, API, EDI, PDF or ERP integration, with no connection to a regulated American network

OpenPeppolA certified Access Point can register and serve US organisations using a permitted participant identifier scheme such as 9959:EIN, under its own Service Provider Agreement and its authority's rules

DBNAllianceOpen to American and international organisations, but requiring separate membership, onboarding and certification. International companies already appear among the certified providers

No general requirement was found in the published DBNAlliance rules for a US legal entity, an American shareholder, a physical office, a local director, a local tax representative, an American "official electronic mailbox" or a US bank account. The published requirements are membership, technical compatibility, SML and SMP, certificates, AS4 and interoperability testing — though commercial, tax, privacy and sanctions requirements need separate checking depending on the service and the states involved.

IPP and WAWF work differently

A European provider does not become a national Access Point in the Peppol sense for these platforms. Typically the agency registers the supplier in IPP; the supplier may then grant access to its third-party billing service, which accepts the IPP Vendor Participation and Rules of Behavior Agreement. For WAWF the supplier needs SAM and PIEE/WAWF registration, and high-volume integrations may use EDI or SFTP. A provider can help technically — but access to the federal platform stays tied to a specific vendor account and contract.

Cross-border and ViDA

ViDA is EU legislation and creates no obligation for a US company as such. Three situations need distinguishing, and only two of them involve ViDA at all:

Direct US → EU customer supplyA third-country transaction. It does not become an intra-EU supply, and the EU digital reporting requirements do not attach to it by virtue of the destination

Through an EU establishment or VAT registrationThe relevant member state's rules apply — and from 1 July 2030, the ViDA requirements for transactions within scope

Selling within a single EU countryThat country's national e-invoicing mandate applies on its own terms, independently of anything American

The practical consequence for a US group is that its European subsidiaries will hit mandates years before anything happens domestically — Poland, France, Belgium, Croatia and others are already live or imminent. The e-invoicing project for a US multinational is usually a European project with an American parent, not the other way round.

Consequences

In domestic B2B and B2C there is no e-invoicing penalty regime, because there is no mandate to breach. What exists is the ordinary law of contract, plus the tax consequences of failing to keep adequate records.

In federal B2G

The consequences are procurement consequences, and they can be sharper than a fine. A payment request submitted outside the required channel may simply not be a valid payment request: it is not processed, the payment clock does not start, it must be resubmitted correctly, and repeated failure is a contract compliance issue. In the DoD environment, where fax, email and scans are expressly not an acceptable electronic form, that is a predictable and avoidable failure mode.

Is an e-invoice the only basis for recovering tax?

The question does not translate. There is no federal VAT and therefore no federal input tax to recover on the strength of an invoice. Deductibility of business expenses for income tax purposes depends on the expense being ordinary and necessary and on being able to substantiate it — with invoices, contracts, payment records and the rest of the accounting trail, in whatever form.

Sales and use tax is a state matter, with its own exemption certificate and documentation rules that vary by state. It is the closest American analogue to the European invoice-evidence question — and it is answered state by state, not federally.

Recordkeeping

The American model rests on retention and later audit rather than on prior clearance. The IRS principle is that records must be kept as long as they may be material in administering the Internal Revenue Code — which generally means until the period of limitations for that return expires.

3 yearsThe base period in the ordinary case

4 yearsEmployment tax records, from the date the tax becomes due or is paid, whichever is later

6 yearsWhere income that should have been reported is omitted and exceeds 25% of the gross income shown on the return

7 yearsFor a claim relating to a loss from worthless securities or a bad debt deduction

Electronic records

The IRS permits EDI and electronic records but requires machine-sensible records containing all the information that would have been required in paper accounting documents. Electronic data must be supplemented where necessary by contracts, price lists, supplier master data and other records. Revenue Procedure 98-25 sets out the requirements where records are maintained in an automatic data processing system — including documenting the format and layout of records and making field definitions and file descriptions available to the Service.

Two implications worth designing for. Electronic recordkeeping does not relieve a taxpayer of the obligation to retain hardcopy records created or received in the ordinary course of business where existing law requires it. And an archive that stores documents without the field definitions and file layouts that make them interpretable is not sufficient — the IRS expects to be able to read the structure, not just the file. State sales tax retention periods are separate again and vary.

How we help

The US is not a compliance problem, it is an integration problem — and usually one half of a transatlantic project:

Peppol BIS Billing 3.0 and EN 16931 for the European side of a US group's operations, where the real mandates are

Addressing on 9959 for the EIN, plus DUNS and GLN where counterparties use them — without treating the EIN as a VAT number

Conversion between EN 16931, UBL 2.1 and the UBL 2.3 the US network expects

EDI 810 and EDI 850 handling for federal and commercial flows that have run on EDI for decades

A clear-eyed answer about IPP and WAWF: what a provider can automate, and what stays tied to the vendor's own account

PDF visualisation alongside structured data, since much of the US market still runs on it

Archiving that keeps the structured record together with its field definitions and layouts

Connection by API, SFTP and CSV, with ERP and IDoc source data

Frequently asked questions

Is e-invoicing mandatory in the United States?

Not as a matter of tax law, and no date has been announced. There is no federal law requiring companies to invoice electronically, to use structured XML, to route invoices through a government platform, to pre-register with the IRS or to report transactions in real time. What is often mandatory is federal procurement invoicing — but that comes from the contract, the FAR and DFARS, not from tax legislation.

Why does the US have no clearance system?

Because there is no federal VAT or GST. The IRS administers income, employment, self-employment, excise and withholding taxes; sales taxes are imposed mainly by states and localities. Without a federal input-and-output tax mechanism there is no reason for a tax authority to receive or approve each invoice — so there is no clearance, no unique government invoice ID, no tax fifth corner and no invoice-level real-time reporting.

Are IPP and WAWF tax systems?

No. The Treasury's Invoice Processing Platform and the DoD's Wide Area WorkFlow are procurement, approval, receiving and payment workflow systems. They exist to get an agency to pay a vendor correctly, not to validate commercial invoices for tax purposes. They are also separate systems: IPP states that invoices under most DoD contracts go through WAWF and that there are no plans to merge the platforms.

Can I send a PDF invoice to a US federal agency?

It depends entirely on the agency and the contract, and the range is wide. The Department of Labor accepts PDF or TIFF and in some cases email. HUD has contracts where invoices go by email. The EPA requires IPP and treats a scanned document only as an attachment to a structured submission. The DoD does not recognise PDF, a scan or email as an electronic form of the primary payment request in WAWF — only EDI, secure file transfer or direct web entry, with PDFs permitted purely as supporting documentation.

What is DBNAlliance, and is it the US Peppol Authority?

It is the Digital Business Networks Alliance, which grew out of the Business Payments Coalition market pilot and governs the US exchange framework — a voluntary, industry-led four-corner network using AS4, SML, SMP, digital certificates and dynamic discovery. It is not the US Peppol Authority: it is a separate network with its own rules, certificates, SML and SMP, and its own accreditation, and no United States Peppol Authority has been published at all.

Does my Peppol certification work on DBNAlliance?

No — these are different trust domains with different certificate authorities. DBNAlliance certification is required separately: membership and onboarding, SML registration, digital certificates, an own or shared SMP, AS4 configuration, interoperability testing over a two-month period, successful Core Invoice exchange with at least three certified service providers and three confirmation letters, then a production certificate and Certified Service Provider status.

Which format does the US network use?

OASIS UBL 2.3 for the Core Invoice and Credit Note between Access Points — not UBL 2.1 and not EN 16931. A participant may exchange with its own provider in an ERP-native format, but the document crossing the network must follow the DBNAlliance rules. US federal law requires none of EN 16931, a CIUS, Peppol BIS Billing 3.0, UBL 2.1, UN/CEFACT CII, Factur-X or ZUGFeRD.

Which identifier do I use for a US business?

EAS 9959, the Employer Identification Number, is the US-specific scheme in the Peppol code list, with D-U-N-S 0060, GLN 0088 and GS1 keys 0209 also usable depending on the specification and registration. Critically, the EIN is not a VAT ID — there is no federal VAT — so any platform that maps the two together will misbehave. DBNAlliance likewise uses DUNS, GLN and US:EIN, so do not assume a single identifier type covers your US counterparties.

Can a European provider serve US clients?

Yes. No federal Access Point licence exists, and no general prohibition was identified. Three routes: ordinary commercial services with no regulated network; OpenPeppol, where a certified Access Point can register and serve US organisations using a scheme such as 9959:EIN; or DBNAlliance, which is open to international organisations but requires its own membership and certification — international companies already appear among its certified providers. No US entity, shareholder, office, director, tax representative, official mailbox or bank account was found as a published requirement, though commercial, tax, privacy and sanctions rules need separate checking.

Can my provider file invoices into IPP or WAWF for me?

Partly. A European provider does not become a national Access Point for these platforms. Typically the agency registers the supplier in IPP, and the supplier may then grant access to its third-party billing service, which accepts the IPP Vendor Participation and Rules of Behavior Agreement. For WAWF the supplier needs SAM and PIEE/WAWF registration, and high-volume integrations may use EDI or SFTP. So a provider can automate a great deal — but access stays tied to the vendor's own account and contract.

Does ViDA affect US companies?

Not as such. A direct supply from the US to an EU customer is a third-country transaction and does not become an intra-EU supply. ViDA bites where the group operates through an EU establishment or VAT registration — from 1 July 2030 for transactions in scope — and a sale within a single EU country is governed by that country's own mandate. In practice a US multinational's e-invoicing programme is usually driven by its European subsidiaries, which face live mandates years before anything happens domestically.

How long must records be kept?

As long as they may be material in administering the Internal Revenue Code — generally until the period of limitations for the return expires. That is three years in the ordinary case, four years for employment tax records from when the tax becomes due or is paid, six years where omitted income exceeds 25% of gross income shown, and seven years for a worthless securities or bad debt claim. Electronic records must be machine-sensible and contain everything paper records would have; Revenue Procedure 98-25 requires documenting record formats and layouts and making field definitions and file descriptions available. Electronic storage does not remove any obligation to retain hardcopy records that existing law requires. State sales tax periods are separate and vary.

Summary

The United States is not a mandate market and, absent a federal VAT, has no structural reason to become one soon. There is no clearance, no continuous transaction control, no real-time reporting, no national B2B or B2C obligation and no announced date. What is compulsory is federal procurement invoicing — through IPP, WAWF or an agency's own system — and that comes from contract and procurement law.

Alongside it, DBNAlliance is building a genuine four-corner network on AS4, SML, SMP and UBL 2.3. It looks like Peppol and is not Peppol: separate rules, separate certificates, separate accreditation, and no tax authority anywhere in the picture.

For a European business the useful framing is this. Your American obligations will come from contracts, not from tax law — and your American parent's biggest e-invoicing deadlines are almost certainly in Europe.

Resources

DBNAlliance — the US open exchange network The exchange framework: policies, standards, certification process and the list of certified service providers DBNAlliance — how to become certified The certification path in full: onboarding, SML, certificates, SMP, AS4, testing and the three-provider requirement DBNAlliance — technical implementation documents The published specifications on GitHub, including the UBL 2.3 Core Invoice profile Invoice Processing Platform (IPP) The Treasury platform used by many civilian agencies — enrolment, EDI options and the vendor agreement PIEE / Wide Area WorkFlow (WAWF) The Department of Defense environment: registration, document types and submission methods DFARS 252.232-7003 The clause requiring electronic submission of payment requests and receiving reports, and what does not count as electronic IRS — how long should I keep records? The periods of limitations that determine retention: three, four, six and seven years IRS Revenue Procedure 98-25 (PDF) Requirements for records held in an automatic data processing system, including formats, layouts and field definitions IRS — automated records The machine-sensible records requirement and how electronic data must be supplemented Peppol Electronic Address Scheme code list Where 9959 for the EIN sits, alongside D-U-N-S, GLN and the GS1 keys European Commission — VAT in the Digital Age (ViDA) The European obligations that reach a US group through its EU establishments and registrations

Need support with e-invoicing compliance?

As a certified Peppol Access Point we provide solutions for sending and receiving electronic invoices securely across Europe — including format conversion, validation and integration with national systems.

Start your free trial