B2B Payments: Business Processing and Challenges to Achieving Straight-Through Processing

In the first process phase, supplier onboarding, a buyer establishes a new supplier relationship. The buyer first evaluates the supplier, collects information (such as the supplier’s legal name, address, contacts, bank account details, payment terms, and shipping and return policies), and records the information as the supplier’s “master data” in its internal system (Figure 1, step 1). Similarly, the supplier records equivalent data of the buyer in its internal system (Figure 1, step 2). Each buyer (or supplier) manages many suppliers (or buyers) and keeps their master data in its internal system.¹ For their internal systems, smaller businesses often rely on accounting software built for small and medium-sized businesses, while large firms typically use enterprise resource planning (ERP) systems (see the appendix for details, including the major providers of these systems and other key platforms and software). These internal systems are foundational to carrying out necessary activities involving business transactions such as populating transactions, validating invoices, and creating auditable records.

The second process phase, procurement and delivery, involves a buyer ordering goods or services and a supplier delivering those goods and services. Once both parties agree to transact, the buyer issues a purchase order (PO) specifying items, quantities, prices, and delivery terms (Figure 1, step 3). Buyers often send POs electronically, via email, electronic data interchange (EDI), an e-procurement platform, or a supplier portal, though some buyers still use fax or mail. A supplier’s accounting system can import a PO automatically if it arrives in a recognized format or through a portal or e-procurement platform; otherwise, the PO is manually entered into the accounting system (Figure 1, step 4). The supplier’s accounts receivable (AR) function then tracks delivery (Figure 1, step 5), and the buyer’s accounting system notes when goods or services are received (Figure 1, step 6).

The third process phase, invoicing, may be the first point at which the exchange channel and format materially affect business process efficiency. After receiving the buyer’s receipt (Figure 1, step 7), the supplier’s AR function generates an invoice, a formal payment request that includes necessary information such as the amount due, due date, and line items describing what was purchased (Figure 1, step 8).² After the supplier sends the invoice to the buyer, the buyer imports the invoice data into its system’s accounts payable (AP) function, either automatically or manually (Figure 1, step 9). An invoice’s exchange channel and format determine whether each side can streamline its processes.³ For example, physical mail requires both sides to handle the invoice manually. For invoices sent electronically, manual handling may still be required; if the invoice format is incompatible with the buyer’s AP software, the buyer will need to enter the invoice data manually. Manual handling may still be required even if an invoice is in a compatible format. For example, although using a supplier portal may let the buyer receive an electronic invoice from its suppliers and import the invoice data directly into its AP system, when each buyer runs its own portal, suppliers must log into each portal manually, creating friction, especially as the number of buyer portals increases. Although no payment methods fully integrate invoicing and payment, some third-party service providers, such as electronic invoice presentment and payment (EIPP) providers, allow buyers to initiate an electronic payment upon the invoice receipt, streamlining these steps.⁴

The fourth phase, payment, encompasses business processes related to payment instructions and receipts as well as remittance advice and receipts. The efficiency of these business processes depends on the payment method. After approving an invoice, the buyer initiates payment from its AP function, drawing on master and invoice data to construct payment instructions (Figure 1, step 10a). When the buyer uses electronic payment methods, the buyer transfers the payment instructions to its bank, either automatically or manually, depending on how the buyer’s accounting system connects with its bank. Payment solutions within or augmented to an accounting system may enable automated bank feeds, which are secure, direct data connections to the business’s bank via application programming interfaces (APIs) or other secure connections. Without this capability, the buyer may need to transfer instructions manually. When the buyer uses checks, AP software may print checks that are subsequently sent via physical mail. To deter fraud, the buyer may also share details of these checks with its bank, either automatically or manually, under Positive Pay arrangements (a fraud mitigation service).⁵ Alternatively, EIPP and third-party payment providers offer electronic payment services by generating split Automated Clearing House (ACH) payments or card payments through partnerships with card issuers.⁶

Along with a payment instruction, the buyer generates a remittance advice confirming the payment to the supplier (Figure 1, step 10b). The remittance advice may be simple, including only invoice numbers, amounts, and dates, or it may contain additional details such as specifying net payment amounts that reflect discounts, reduced obligations, and other adjustments. Whether the remittance advice travels with the payment and how much detail the remittance data carry with the payment varies by payment method. A check can contain detailed remittance data as its stub, and wire and instant payments can carry rich remittance data along with the payment; in contrast, ACH and card payments sometimes cannot carry rich remittance data.⁷ When buyers send remittance data to their suppliers separately from payments, they use various transmission mechanisms, including email, EDI, supplier portals, or accounting systems directly if the suppliers also use the same system.

The final process phase, reconciliation, is the process of both buyers and suppliers comparing different sets of data, identifying and investigating differences, and taking corrective action when necessary. When the supplier receives the payment and remittance advice (Figure 1, steps 11a and 11b, respectively), its AR function records the payment and matches it against remittance and invoice records to verify accuracy and completeness (Figure 1, step 12). Whether this runs automatically or requires manual handling depends on the payment method and the format of the remittance data. Matching may be automatic when the supplier receives structured remittance data (such as data using an international standard ISO 20022 format) along with the payment, while manual handling is needed when checks are used for payments (unless a lockbox service is used), remittance data are detached from the payment, or the supplier’s AR function lacks an automated bank feed.

Key challenges to advancing STP

While manual processing involves frictions that create inefficiencies for businesses, STP automates and streamlines business processes, reducing costs and improving overall operations. However, multiple sequential process steps create challenges for businesses to advancing STP, as frictions may be present at one or more steps, and these challenges help explain why migrating B2B payments from checks to electronic methods has been gradual and incomplete. Challenges to STP stem from the inherent complexity of B2B transactions, coordination difficulties among many diverse stakeholders, and technical barriers related to message format and data exchange.

Challenges related to invoice exchange and presentment

Today, invoicing mechanisms are fragmented, requiring each business to use many different methods to exchange invoices with its trading partners. Typically, invoicing processes are independent of the payment methods that are now widely used, though instant payments have the potential to integrate invoicing and payments (discussed in part three of this series).

Each invoice exchange method has pros and cons, as each requires different technical capabilities, security protocols, and business processes. Paper invoices sent via physical mail and PDF invoices sent via email offer broad accessibility because nearly every business can use these methods with little technical capability and sophistication. However, these methods offer limited security and are vulnerable to fraud and scams. For example, criminals often compromise business emails or intercept physical mail to send fraudulent invoices.⁸ Generating and processing paper invoices also involves significant manual handling in printing and mailing. Upon receipt of paper or PDF invoices, buyers may need to manually scan or type invoice data into their accounting system.

Other electronic invoice (e-invoice) exchange methods, such as EDI, supplier portal, EIPP platform, and B2B network, offer better security and more automation but limited accessibility. For instance, through an EIPP platform or a B2B network (such as SAP’s Ariba Network, Oracle Business Network, and NetSuite Commerce), authenticated suppliers can securely create and send invoices to their buyers automatically, and authenticated buyers can import these invoices into their accounting systems automatically.⁹ However, because of a lack of interoperability among platforms and networks, both buyers and suppliers need to join the same platform (or network) to exchange invoices, requiring each business to join multiple platforms and networks.¹⁰ The recent proliferation of supplier portals has caused further fragmentation. Large buyers often use their own supplier portals to exchange invoices (and to share remittance data and payment status), requiring suppliers to log into multiple portals to upload and download the information they need for each buyer relationship. This practice creates “supplier portal fatigue,” or the burden of managing numerous separate portal relationships, each with different login credentials, interfaces, and procedures.

Each invoice exchange method often uses a unique message format, adding further challenges. The information required in an invoice also varies based on industry, use case, idiosyncratic business practices, and back-office systems used among the parties. For example, an invoice in the construction industry may need to reference multiple projects, retention amounts, and lien waivers, while an invoice in the healthcare industry may need to include detailed service codes and insurance information. These variations in information requirements make it difficult to standardize invoice formats and exchange mechanisms across industries and use cases. This complexity helps explain why many businesses continue to rely on paper or PDF invoices delivered via mail or email with unstructured formats; although they cannot be processed automatically, they can accommodate virtually any information requirement.

Challenges related to electronic payments

The proliferation of payment and remittance message format standards, and the implementation variations of any given standard, is a fundamental barrier to advancing STP and adopting electronic payment methods. As discussed in the previous section, some electronic payment methods allow remittance data to travel along with the payment, and they typically use the same message format standard for both payment and remittance data. Wire and instant payments use the ISO 20022 format, card payments use the ISO 8583 format, and ACH payments use the legacy ANSI ASC X12 EDI format. However, even the same message format can be implemented slightly differently. When remittance data travel separately from the payment, the remittance data may take one of many proprietary formats developed by individual businesses and remittance exchange platforms, each with different required remittance information based on industry, use case, and idiosyncratic business practices. Translation between standards or implementation variations may be required at multiple points in the payment or remittance data processing chain, and each translation point introduces the potential for errors, data loss, and processing delays that undermine the promise of STP.

The broad use of legacy accounting software and ERP systems, especially among small and medium-sized businesses, is another key barrier to advancing STP. Because these legacy systems are geared toward the historically prevalent payment method of check, they may not easily integrate with electronic payment systems or enable automated bank feeds. Without updated systems, businesses need to transfer payment instructions manually to their banks or import payment receipt information manually from their bank into their system. In addition, these systems may not support numerous message formats simultaneously. Adapting and updating these legacy systems represents a significant technical and financial burden.

Coordination between the buyer and supplier to determine the electronic payment method to use for a payment is yet another key barrier to the adoption of electronic payment methods (AFP 2022). Unlike checks, which businesses almost universally accept, certain electronic payment methods such as credit and debit cards and instant payments are not accepted by some suppliers, especially smaller ones. Furthermore, unlike checks, the buyer often needs to know the supplier’s bank account information to initiate an electronic payment.

Challenges related to reconciliation

Although some electronic payment methods allow remittance data to travel along with the payment, remittance data often travel separately from the payment. As a result, remittance data exchange and processing present many of the same challenges to STP as invoice exchange and processing, including the proliferation of exchange methods, lack of interoperability, and portal fatigue. However, remittance data also present challenges related to reconciliation.

Reconciliation involves comparing multiple datasets, including payment data, remittance data, and invoices. When remittance data travel separately from the payment, either because the payment method cannot accommodate sufficient remittance data or because business processes separate the remittance advice from payment initiation, reassociating the detached remittance data with the payment requires manual handling. Suppliers’ AR staff must match incoming payments to remittance advice reports that may arrive hours or days earlier or later via a completely different channel. This manual matching process is time consuming and error prone and undermines the efficiency gains that electronic payments are meant to provide. When checks are used for payments, remittance data often travel with the check, removing the need for reassociation, though manually entering payment and remittance data into the accounting system is likely still required.

Complex relationships among invoices, payments, and remittance advice reports also introduce manual intervention into reconciliation. For example, if a single remittance advice references multiple invoices, the supplier’s AR system needs to unpack the advice into its component parts. Alternatively, a single payment may be aggregated to cover multiple underlying remittance items, and each of these items may be transmitted individually. In this case, the AR system needs to be capable of complex parsing logic to fully automate receipt of payment and remittance items.

Further manual intervention may be needed if invalid information is included in the remittance advice, creating an exception. Missing data elements, incorrect invoice numbers, or other data-quality issues may prevent automated matching among the invoice, payment, and remittance advice.

Partial solutions to advancing STP

Despite numerous challenges, several efforts are underway to facilitate STP. First, the business community has made some progress in addressing challenges related to invoice and remittance data exchange and processing. Structured message delivery networks (MDN)—that is, specialized organized systems for transmitting, routing, and delivering data according to a predefined, consistent message format—provide enhanced message formatting and delivery confirmation capabilities. However, these networks face the same coordination challenge as other B2B networks; namely, they require both suppliers and buyers to join, and a business may need to participate in multiple MDNs to transact with all trading partners. To overcome this market fragmentation issue, the Digital Business Networks Alliance (DBNAlliance) launched the e-invoice exchange network, in which a business establishes a single connection with one of the “access points.” Access points exchange structured e-invoices and e-remittance advices on behalf of businesses regardless of the business’s accounting system, platform, or network (DNBAlliance, 2026).

Second, the payments industry has now standardized certain message formats. In 2017, the Business Payments Coalition published a catalog of electronic invoice technical standards available in the United States (Business Payments Coalition, 2017). More recently, Nacha provided guidance on mapping ISO 20022 remittance information to ACH addenda records, helping bridge the emerging ISO 20022 standard and the established ACH format (Nacha, 2023). Similarly, the Accredited Standards Committee (ACS) X9 developed a best-practices guide for remittance information exchange to support all electronic payments in 2022 (ACS X9, n.d.). In 2024, the DBNAlliance adopted the X9 ISO 20022 e-remittance information standard for use in its exchange framework (DBNAlliance, 2024, 2025). While these efforts demonstrate progress, the standards are not universally adopted and can sometimes be applied differently by payment rail, provider, or use case.

Third, general technological advances have made some business processes more efficient. Artificial intelligence and machine learning tools, including optical character recognition and automated invoice and remittance data extraction capabilities, can fill some of the gaps created by format variations. These emerging technologies read and process payment-related information across multiple channels and formats. However, automated extraction is imperfect, often requiring human review and correction, and deploying and maintaining these technologies adds to the overall cost and complexity of B2B processing.

Summary

Business processes involve multiple steps across five phases, including supplier onboarding, procurement and delivery, invoicing, payment, and reconciliation. The payment methods used for B2B payments affect not only payment processes but also invoicing and reconciliation processes, with checks requiring a significant amount of manual handling and creating friction at various steps. Electronic payment methods have the potential to facilitate STP, reducing the need for manual intervention in B2B transactions and streamlining business processes.

To advance STP, however, businesses need to overcome challenges stemming from the inherent complexity of B2B transactions, coordination difficulties among diverse stakeholders, and technical barriers related to message format and data exchange. Partial solutions to address these challenges have begun to emerge from business communities and the payments industry and through general technological advances such as artificial intelligence and machine learning. The last part of this three-part briefing series will explore the potential of instant payments to make further progress in addressing these challenges.