EIPP, Biller Portals and B2B AR Networks. Operate invoice presentment, supplier and buyer portals, four-corner document exchange, approval, payment handoffs, corrections and ERP reconciliation.
A maintenance supplier sends a $28,500 invoice to a manufacturing customer. The supplier's portal says delivered. The buyer's accounts-payable system says the purchase-order reference is invalid. A service manager has approved the work by email, but the invoice has not entered the buyer's payment run. The supplier asks its bank why an electronic invoice has not produced an electronic payment.
Chapter 43 showed how payment, remittance and open invoices come together in cash application. This chapter moves upstream to the systems that present invoices, exchange business documents and support approval and payment selection. Electronic invoice presentment and payment, or EIPP, can connect those activities, but its name does not make them one financial event.
Invoice delivery proves that a document reached a defined destination. Business approval establishes a decision about the obligation. Payment execution moves value through a separate banking mechanism. A portal must preserve all three meanings.
For a roughly 60-minute core session, spend about 35 minutes on Section 2 and Sections 6–10. For the next 10 minutes, use the chapter’s three diagrams to separate invoice delivery, approval, payment execution and cash application. Use 10 minutes to work through one case in Section 15, then spend the final 5 minutes explaining: Which evidence distinguishes an invoice rejected by the buyer from a payment that failed at the bank? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Businesses, invoices, internal states and approval designs are fictional. Network participation, document profiles, payment capabilities and contractual commitments must be confirmed from current provider documentation. Examples of official services illustrate specific arrangements, not universal US invoicing rules.
Chapter navigator
- What EIPP is intended to improve
- Supplier portals, buyer portals and exchange networks
- Onboarding the business and its authorized users
- Creating a usable invoice record
- Structured documents, UBL and implementation profiles
- Document exchange and the four-corner model
- Buyer validation, approval and dispute workflow
- Payment selection and authorized initiation
- Where money moves and how settlement is evidenced
- Remittance and cash application back to the ERP
- Credits, rejections and duplicate invoices
- Security, fraud and separation of authority
- Operating calendars, service commitments and resilience
- Implementing the service inside a bank
- Worked cases and implementation decisions
- Role checklist and learning closure
1. What EIPP is intended to improve
EIPP brings invoice presentation and payment-related activity into an electronic workflow. A supplier can make invoices available, a buyer can review them, and a supported service can help the buyer initiate payment or communicate its payment decision. The business purpose is to reduce missing documents, unclear approval status and disconnected remittance, while preserving the authority needed at each stage.
The maintenance supplier's immediate problem is not a failed settlement. Its invoice has not passed the buyer's reference validation. The buyer's service manager may agree that the work occurred, but accounts payable still needs the information and approval required by its process. Calling the invoice delivered does not explain why it is not ready for payment.
A useful portal makes those states visible. The supplier can see whether the invoice was received, rejected for a correctable data issue, awaiting review, disputed, approved or associated with a payment. Those are illustrative business states; the exact labels depend on the service. Each should identify the evidence behind it and the participant responsible for the next action.
Electronic invoicing is more than emailing a PDF. A PDF can be useful to a person, but structured invoice data allows systems to validate and process fields without rekeying the whole document. Federal Reserve payments-improvement material describes electronic invoices as an important part of improving business payment efficiency. The practical benefit comes from usable data and connected processes, not simply replacing paper with a screen.
Keep the scope anchored to receivables
For the supplier, EIPP is a receivables service: issue the correct invoice, deliver it to the right customer, resolve questions, receive payment information and apply the resulting cash. For the buyer, the same interaction sits within accounts payable and procurement. The bank should understand both views without expanding the service into an unsupported promise to manage every purchasing or accounting decision.
A bank may provide a supplier portal, connect to a business-document network or integrate a payment service into an existing platform. Each approach can be useful. The important question is what the bank actually controls and what information it receives. A bank that only supports the eventual ACH payment cannot independently certify that the buyer accepted the underlying goods.
The implementation should define a measurable business outcome. Reducing invoices rejected for missing references is different from reducing time after approval to payment. Improving remittance quality is different from accelerating interbank settlement. Separate measures reveal where the service helps and where another process still creates delay.
For the maintenance supplier, success means that the buyer receives a usable invoice, can resolve the incorrect purchase-order reference, records its approval and supplies traceable payment information. The eventual bank receipt can then be linked to the invoice through the cash-application process from Chapter 43. That is a continuous business lifecycle with distinct events, rather than an electronic document somehow turning itself into money.
2. Supplier portals, buyer portals and exchange networks
A supplier-led portal presents one supplier's invoices to its customers. Buyers may log in to review balances, download documents, raise questions and use supported payment methods. The supplier controls the receivables context, while the buyer decides which authorized users can act for it. The portal's payment features depend on the supplier's banking and processing arrangements.
A buyer-led portal receives invoices from many suppliers and connects them to the buyer's procurement and accounts-payable process. The buyer can specify required references, submission formats and review steps. Suppliers may use the portal because it is the buyer's designated submission channel. Successful submission does not necessarily mean the invoice has passed every business check.
A B2B document-exchange network connects businesses through service providers and agreed document standards. It can reduce the need for every supplier to build a separate technical connection to every buyer. The network exchanges documents and related information; it is not automatically the banking system that clears or settles payments for those documents.
The Digital Business Networks Alliance describes its US Open Exchange Network using a four-corner model: supplier, supplier access point, buyer access point and buyer. Its published onboarding material identifies an invoice and credit-note format based on OASIS UBL 2.3. That is a network-specific description. It should not be replaced with whichever UBL version happens to be newest in the standards catalogue.
Choose the model for the trading relationship
A small supplier with a few large buyers may need to use several buyer portals. A larger supplier may prefer a provider that connects its ERP to multiple trading partners. A bank-hosted supplier portal may be suitable where buyers want a straightforward view and payment option. The right design depends on the users, document volume and integration needs rather than a claim that one model eliminates all other channels.
Portal fragmentation creates operational work. A supplier may need to retrieve rejection reasons from several sites, maintain user access and reconcile status labels that mean different things. A consolidated dashboard can help, but it must preserve source and meaning. Mapping every external 'accepted' status to 'approved for payment' would make the dashboard simpler and less accurate.
Network participation also has limits. A provider's membership or technical connectivity does not establish that every desired buyer is reachable, accepts every document type or has authorized a particular commercial relationship. Onboarding should verify the actual endpoints, supported profiles and business identifiers. A directory match should not be treated as permission to submit any invoice to any listed business.
The bank's product documentation should explain the chosen model and its boundaries. Who hosts the invoice? Who supplies the authoritative status? Who can approve it? Which payment methods are supported? Who handles a rejected document? Answering those questions prevents a customer from interpreting 'network connected' as a guarantee of payment or universal interoperability.
A portal can solve one problem while creating another
A supplier-led portal gives the supplier a consistent way to present invoices, but a large buyer may still need those invoices inside its own approval system. If the buyer must download a PDF and rekey the data, the supplier's digital delivery has not created end-to-end structured processing. The bank should assess the receiving workflow as well as the portal experience it directly supplies.
A buyer-led portal can improve the buyer's validation while requiring suppliers to maintain several logins and manually retrieve statuses. A service provider may reduce that work through supported integration, but it must preserve each buyer's requirements. A generic upload connector that omits a required service reference can reproduce the same rejection at greater scale.
A network connection can reduce bilateral technical connections where counterparties and profiles are supported. It does not eliminate the commercial onboarding between buyer and supplier. The buyer still needs to recognize the supplier relationship and the invoice's purpose. Technical reachability and an approved trading relationship should remain separate records.
The bank can use these observations to choose a realistic initial scope. A supplier with a concentrated buyer base may benefit most from correcting recurring reference problems in a few buyer workflows. Another may benefit from structured exchange across many counterparts. The service should be designed around observable work and exceptions rather than a general promise that every invoice becomes touchless.
The customer should know which channels remain in use during transition. If portal and email submissions run in parallel, define which is authoritative and how copies are identified. Otherwise an electronic transformation project can temporarily increase duplicate invoices and payment risk by adding a new channel without controlling the old one.
3. Onboarding the business and its authorized users
Onboarding should establish the legal business identity, trading relationships, relevant customer or supplier identifiers and authorized users. Those records determine where documents go and who can view or act on them. A corporate name alone may be insufficient when a group contains several legal entities, divisions or payment centers.
For the maintenance supplier, the buyer's plant location may order the work while a central accounts-payable entity processes invoices. The portal should capture the appropriate bill-to entity and required reference. Sending an invoice to the plant manager's email may be commercially familiar but still fail the buyer's official submission process. The service should make the correct destination clear before invoices accumulate.
User roles should reflect business authority. A supplier clerk may create a draft invoice, a supervisor may release it, and a finance administrator may maintain collection instructions. On the buyer side, a receiving manager may confirm service completion while accounts payable validates the invoice and an authorized payment approver releases funds. Combining these roles for convenience can allow one compromised account to create and pay a false obligation.
Access should be scoped to the relevant entities and documents. A user serving one subsidiary should not automatically see every group company's invoices or bank details. Shared-service users may need broader access, but that access should be explicit and reviewable. The portal should preserve which entity a user acted for when submitting or approving a document.
Validate changes as carefully as initial setup
A change to a supplier's collection account can redirect future payments. It should follow a separate, controlled process with appropriate verification and approval. The FBI's business-email-compromise guidance is directly relevant: changes to payment details should be verified rather than accepted solely from a message. A portal notification does not make the change safe if the administrator account was compromised.
The service should distinguish contact changes from financial changes. Updating a notification email may affect who receives invoice alerts; changing a payment destination affects where funds go. Both deserve controls, but they have different consequences and should not be hidden behind a generic profile-edit permission.
Onboarding also establishes supported document and payment capabilities. Can the buyer receive structured invoices, credit notes and status responses? Does the portal support purchase-order references or service-period details required by this buyer? Can it initiate the selected payment method, or only record an external payment reference? A sales demonstration should not substitute for this capability confirmation.
A controlled first transaction should test the complete relationship. Submit a representative invoice, receive its actual validation and business status, correct a known issue, and trace the payment information into the supplier's receivables process. The test should use authorized test arrangements and avoid creating a real duplicate obligation. A successful login proves only that access works, not that the trading relationship is operational.
Deactivation should preserve history while removing inappropriate future access. When an employee leaves or a supplier relationship ends, the portal still needs records for existing invoices and investigations. Deleting the identity entirely can make prior approvals difficult to explain. The system should retain the relevant audit evidence under the applicable retention policy.
4. Creating a usable invoice record
An invoice record should identify the supplier and buyer, the obligation, amount, currency, relevant dates and references required by the trading relationship. Line detail may include goods or services, quantities, prices and applicable adjustments. The exact fields and validation rules depend on the document profile and business arrangement. The chapter does not prescribe one universal US invoice schema.
The supplier's ERP should normally remain the controlled source for issued invoice data under the chosen architecture. If a portal can create invoices directly, the process must ensure that those invoices also enter the supplier's accounting records. Two independent invoice-creation systems can produce duplicate numbers or obligations unless their responsibilities are explicitly coordinated.
The $28,500 maintenance invoice may include a service period, purchase-order reference and work-order evidence. Those details help the buyer establish what it is being asked to pay. A polished PDF cannot compensate for an incorrect legal entity or missing required reference. The portal should validate what it can before submission and distinguish technical completeness from commercial correctness.
Totals need consistent arithmetic. Line amounts, discounts, charges and taxes should reconcile to the document total according to the applicable profile and business rules. Tax determination itself may require specialist systems and jurisdiction-specific analysis; a bank portal should not claim that schema validation proves tax compliance. It can validate supplied fields and arithmetic without certifying the underlying tax treatment.
Preserve the issued document
Once an invoice is issued and delivered, later changes should follow a controlled correction process. Silently editing the amount while retaining the same visible version can leave the buyer and supplier working from different obligations. The appropriate use of cancellation, replacement or credit documents depends on the arrangement and accounting policy, but the history must remain clear.
Attachments can support an invoice without replacing its structured data. A signed work record may explain service completion; a purchase-order image may help investigate a reference. The service should link attachments to the correct document version and protect them appropriately. An attachment containing new payment instructions should not automatically update the supplier's verified bank details.
Identifiers should be unique within their intended scope. An invoice number may be unique only within a supplier entity or fiscal series. A network message identifier is a different object used for document transport. The platform should retain both and avoid assuming that a transport retry creates a new commercial invoice.
A buyer's reference can be mandatory for its processing even where it is not a universal legal invoice requirement. The customer explanation should say that the buyer requires the field, rather than present it as a federal invoicing rule. This distinction helps suppliers understand why the same document may be accepted by one trading partner and rejected by another.
Good invoice data improves later payment and application. If the buyer retains the supplier's invoice identifier through approval and remittance, the eventual receipt is easier to match. That benefit depends on maintaining the reference through the full process, not simply including it in the initial document and discarding it during export.
Service acceptance and invoice acceptance differ
The buyer may confirm that maintenance work occurred while still requiring a corrected invoice. The service manager's approval supports the commercial facts; accounts payable may need the proper entity, purchase-order reference and amount before processing. The portal should retain both records rather than force the supplier to choose between saying the work was accepted and saying the invoice was rejected.
A receipt of goods can also cover only part of an order. If an invoice bills the full order, the buyer may need to review the difference. The platform should preserve quantities and line relationships where the supported profile allows them. It should not infer that a matched purchase-order number means every invoiced item has been received and approved.
For recurring services, the service period can matter as much as a goods-receipt record. Two invoices with different numbers can cover the same month accidentally. Duplicate controls should consider the business pattern where appropriate, while avoiding automatic rejection of legitimate separate services. A review flag is often more appropriate than an unsupported final decision.
Supporting evidence should remain attached to the relevant version. If the supplier replaces a document to correct the buyer reference, the service record should not disappear. If the amount changes, the buyer should be able to see whether the same evidence still supports the revised charge. The document history should help the reviewer make a decision without reconstructing the relationship from separate emails.
This is where invoice quality becomes operationally valuable. The service supplies the information needed for the buyer's decision and identifies missing evidence early. It does not certify performance of the underlying contract merely because all fields are populated.
5. Structured documents, UBL and implementation profiles
A structured invoice uses defined fields and relationships that systems can process. OASIS Universal Business Language provides document models including invoices and credit notes. X12 also provides business transaction sets, including Invoice 810 and Payment Order/Remittance Advice 820. These standards serve business-document functions; their use does not automatically establish a payment rail or a settlement event.
The standard and the implementation profile are separate. A broad standard may permit many optional fields, while a network or buyer profile requires particular identifiers, code lists and business rules. A document can satisfy an XML schema and still fail the receiving profile. The implementation team must obtain the actual supported profile and version rather than rely on the standard's name alone.
The DBNAlliance's published onboarding description uses UBL 2.3 for invoices and credit notes. OASIS has also published UBL 2.4. Those facts are compatible: a network can use a specific supported version even when a later standard exists. A bank should not upgrade transmitted documents unilaterally because a newer version appears in a catalogue.
An invoice document is not an ISO 20022 pacs payment message. A request-for-payment message in a supported payment service is also different from the complete commercial invoice and its approval history. The systems may link these objects through references, but they should not collapse them into one object called an invoice payment. Each has its own schema, purpose and processing rules.
Validate at several levels
Technical validation can check whether the document is well formed and conforms to the selected schema. Profile validation can check required identifiers, code values and business constraints. Business validation can check whether the buyer recognizes the purchase order, entity, amount or service. Approval then records an authorized decision about the obligation. A successful earlier check should not imply that all later checks passed.
A conversion service must preserve meaning. Transforming a supplier's export into UBL or another agreed format should retain amounts, signs, currencies, references and document relationships. If a source lacks required information, the service should request or flag it rather than invent a value that makes the file technically valid. A fabricated purchase-order number may pass a length check and still make the invoice unusable.
Free text can be valuable, but critical structured fields should not be hidden only in a note. If the buyer needs an invoice reference for payment matching, put it in the agreed field and preserve it in the remittance. The human-readable rendering should be consistent with the structured record so that users do not approve one amount while the system processes another.
Testing should include realistic edge cases: several line items, a credit note, a partial commercial adjustment, a long reference and characters that the source system normally uses. The goal is to verify semantic fidelity across systems. A sample containing one short line and a round total does not establish that the mapping handles the supplier's actual invoice population.
The bank should publish or supply the relevant interface documentation through the service's approved process. This chapter provides the conceptual distinctions and official standards references, not a production-ready invoice payload. Inventing an XML example with unverified mandatory fields would undermine the accuracy needed for implementation.
6. Document exchange and the four-corner model
In a four-corner exchange model, the supplier submits through its service provider or access point, which exchanges the document with the buyer's access point for delivery to the buyer. The model separates the businesses from the technical providers connecting them. It can support interoperability without requiring every supplier to use the buyer's own portal directly.
The DBNAlliance describes this arrangement for its US Open Exchange Network. Its exchange framework concerns business documents and related exchange standards. The bank should explain that role accurately: the access points transport and process documents under the framework; they do not become the payer's and payee's settlement banks merely because there are two providers in the diagram.
A document needs a verified destination and a supported document profile. Provider discovery and routing should follow the network's actual specifications. This chapter does not invent directory field names, transport headers or mandatory API endpoints. Those implementation details must come from the current network documentation and participating provider.
The diagram shows document delivery and status returning through the exchange relationship. The banking payment path is separate. A successful access-point exchange does not prove buyer approval or movement of funds, and a later bank payment must retain a reference that connects it to the commercial invoice.
Delivery acknowledgments have a defined scope
A sending provider may acknowledge receipt from the supplier before the receiving provider or buyer accepts the document. Each acknowledgment should identify the stage and original document. The portal should avoid displaying a broad 'accepted' label when only the sender's upload service has received the file.
Retries should preserve document identity and follow the exchange service's duplicate rules. If the sending provider loses a response, it should establish whether the original document was accepted before presenting a duplicate as a new invoice. The buyer's system should also detect repeated commercial documents using the appropriate supplier and invoice context, not only a transport message identifier.
A provider outage may delay delivery while the supplier's ERP already records the invoice as issued. The service should preserve that distinction and provide a supported recovery process. Marking the invoice cancelled merely because transport failed could create an accounting inconsistency. The supplier may need to resend the same document or use an agreed alternate route without creating another obligation.
A network can improve exchange reliability while leaving buyer-specific business validation intact. The maintenance invoice may arrive successfully and still be rejected because the purchase-order reference is wrong. That outcome should return as a business issue the supplier can correct. It should not be reported as a bank-payment failure.
A bank integrating with an exchange network should test both directions: document delivery and usable response information. Suppliers need to know what happened after submission. A service that sends documents reliably but cannot return actionable rejection information may simply replace a paper chase with a digital one.
Trace one document across different identifiers
The supplier's invoice number identifies the commercial document in its own records. The sending provider may assign a submission identifier, the exchange may use a message identifier and the buyer's ERP may create an internal document number. These references can all be valid at the same time. The integration should retain their mapping rather than overwrite the supplier's reference with the newest technical value.
If the buyer reports an error using its internal number, the supplier's support team should still be able to find the original invoice. If the sending provider investigates delivery using a message identifier, it should be able to connect that message to the same commercial record. A shared reference map reduces the need to send full invoice copies repeatedly through support channels.
An amended document should identify its relationship to the original under the agreed process. A transport retry normally represents the same document event, while a corrected commercial document can have a different version or relationship. Confusing these cases can either suppress a valid correction as a duplicate or accept a replay as another invoice.
The bank should test a lost acknowledgment deliberately. Have the sender retain an uncertain state, establish the receiver's actual result through the supported procedure and resume without creating another obligation. Then test a business rejection after successful delivery. The system should retain both the delivery evidence and the later rejection rather than choose only one status.
The practical operating record is a chain of references with event meanings. It lets each participant use its own system identity while preserving the business document that connects them. That is more dependable than requiring every system to share one identifier that some participants cannot support.
7. Buyer validation, approval and dispute workflow
Buyer processing begins by identifying the supplier, invoice and relevant obligation. The buyer may compare the invoice with a purchase order, receipt of goods or service approval according to its own process. These are business controls. The bank should understand their effect on payment readiness without presenting every buyer's policy as a US regulatory requirement.
The maintenance invoice fails because its purchase-order reference is invalid. The portal should return a specific, appropriate reason and a correction path. If the supplier supplied the wrong reference, it can repair the document through the agreed process. If the buyer's master data is incomplete, the buyer must correct its own record. A generic rejection code should not conceal which party can actually resolve the issue.
Approval should identify the authorized user or process, scope, time and relevant document version. An email approving the work may be supporting evidence, but the buyer's payment-control process may require a separate approval. The portal should not infer authority merely because a message came from someone at the buyer's domain.
Partial approval needs a clear representation. The buyer may accept most work and dispute one line. The system should preserve the approved amount, disputed amount and reason rather than force an all-or-nothing status. The supplier can then decide whether to issue a credit, provide evidence or pursue the disputed amount under the commercial agreement.
Avoid treating silence as agreement
A delivered invoice that receives no response may simply be waiting in a queue. Unless the actual contract and applicable law establish a particular effect, the platform should not mark it approved merely because a reminder period elapsed. Internal aging rules can escalate the item without inventing buyer consent.
Dispute collaboration should keep evidence attached to the relevant invoice and line where possible. A buyer's comment, supplier response and supporting service record should remain versioned and accessible to authorized participants. An informal chat message should not alter the invoice amount unless an approved business action records that change.
Approval can also be withdrawn or changed before payment under the buyer's process. The system needs to determine whether a payment instruction has already been released and what actions remain available. A change to the invoice workflow does not automatically cancel an external bank payment. Coordination with the payment service is necessary to avoid conflicting states.
The supplier's collections team should see the real reason for delay. An invoice awaiting buyer approval requires a different conversation from one approved but scheduled for payment next week. A payment already sent but not applied belongs to the receivables investigation described in Chapter 43. Accurate states let staff contact the right team with a useful question.
The bank's EIPP service should preserve this business logic naturally. It can help route tasks and provide evidence, but it should not decide a disputed service claim unless the customer has explicitly contracted for an appropriate function and authority. Document automation is most useful when it makes the decision clearer, not when it makes the decision invisible.
Approval thresholds are customer policy, not network limits
A buyer may require additional approval above an internal amount or for particular supplier categories. Those thresholds belong to its governance and should be configured and described as such. They are not maximum invoice amounts imposed by a document network unless the network separately states a relevant technical or service restriction.
A change to the invoice amount should trigger the buyer's policy for reapproval. Suppose a manager approved $27,000 and a corrected document later shows $28,500. The platform should not reuse the earlier approval without assessing its scope. The difference may be a valid correction, but the payment authority must still match the actual amount and required approval chain.
Delegation needs similar care. A substitute approver may act during an employee's absence under the buyer's policy. The record should identify the delegation and action rather than make it appear that the absent employee approved the invoice. A system administrator's ability to maintain users should not automatically include authority to approve commercial obligations.
The supplier benefits from useful status without needing access to the buyer's entire internal control structure. It may be enough to show that approval is pending with the buyer and identify a supported contact path. Exposing individual employees' sensitive details or internal risk logic is unnecessary where it does not help resolve the invoice.
The bank's implementation team should therefore separate internal workflow evidence from external status presentation. Both should be accurate, but they serve different audiences. The supplier needs to know what action is required; the buyer and auditor need to know which authorized decision occurred.
8. Payment selection and authorized initiation
Once an invoice is ready for payment, an authorized buyer can select the amount, date, funding account and supported method. The portal may prepare a payment instruction for approval, connect to a bank service or record a payment initiated elsewhere. These are distinct capabilities. A button labeled pay should state which action it actually performs.
The payment instruction should identify the current invoice version and amount selected. If the buyer pays several invoices together, retain the allocation and any approved credits or deductions. That information becomes the remittance needed for cash application. Losing it at the moment of payment defeats much of the benefit of structured invoicing.
Authority to approve an invoice is not necessarily authority to release a payment. A procurement manager may confirm that work was completed while treasury controls the bank account. The portal should enforce the customer's actual roles and approval process. A user who can view an invoice should not automatically be able to debit a corporate account.
Where the service supports ACH debit collection, the required authority and business arrangement must exist. Where it supports a buyer-initiated credit, the buyer's bank or payment provider executes under its own controls. Card acceptance uses the supplier's acquiring arrangement. An external payment reference entered manually is information about a claimed payment, not independent proof that a bank accepted it.
Requests for payment remain requests
A supported request-for-payment service can present an amount and reference to a payer, who may choose to respond through the available banking process. The request itself does not debit the account or settle the invoice. The bank should confirm the actual service capabilities, message profile and participant support before designing the journey around it.
An EIPP invoice and a rail-specific payment request may contain overlapping information, but their roles differ. The invoice describes the commercial obligation and supporting detail. The payment request asks for a financial action in the relevant service. The implementation should link them and prevent stale or duplicate requests after the invoice has been paid or changed.
A future-dated payment remains subject to its actual execution and funding process. Invoice approval does not reserve money in the buyer's account unless a specific service has created a supported reservation or funded position. The supplier's portal should not label the approved amount as cash received merely because the buyer chose a future date.
Cancellation should be precise. Cancelling a draft payment instruction can be straightforward within the service. Cancelling an instruction already released to a bank may require inquiry and the appropriate rail procedure. Cancelling an invoice or issuing a credit note does not by itself recover a completed payment. The workflow should display those dependencies so users understand the action they are taking.
The bank should test the payment handoff using actual response meanings. Accepted for processing, authorized, scheduled and settled should not all map to a single completed status. The supplier and buyer need to know what has happened and which obligations or risks remain.
9. Where money moves and how settlement is evidenced
The document network and the banking payment path should remain visibly separate. Invoice exchange moves business information. Payment initiation sends an authorized instruction into the chosen financial service. Clearing and settlement follow that service's rules and arrangements. Supplier account posting and invoice application then connect the received value back to the commercial obligation.
For an illustrative ACH payment, the actual ACH processing and settlement arrangements apply. For a wire, the relevant wire service governs settlement and recovery. For an instant credit transfer, the supported instant-payment service governs acceptance and settlement. For a card payment, authorization, clearing, settlement and merchant funding remain separate. The earlier rail chapters provide those details; EIPP does not create a new common settlement rule across them.
If buyer and supplier use an internal book transfer at one bank, the money movement occurs through the bank's account entries under that service. There need not be interbank clearing. The invoice exchange still remains a separate business-document event. A four-corner document diagram should not be reused as though it shows the bank's ledger transfer.
The diagram follows an approved invoice into an authorized payment and then into the actual banking mechanism. The supplier's bank evidence supports financial receipt. Application to the invoice completes the receivables task, while the document network's earlier delivery acknowledgment remains evidence of document exchange only.
Payment status should name its source
A buyer can report that it has initiated payment. A bank can report acceptance or a relevant account event. A supplier can report application to its receivable. The portal should show the source and meaning where it matters. A manually entered payment date should not appear indistinguishable from a bank-confirmed receipt.
The supplier may receive one bank credit covering several invoices or buyers through a provider arrangement. The portal needs the individual payment and remittance records plus a bridge to the aggregate settlement. A net funding amount after fees cannot simply be divided across invoices without the supporting transaction population.
Settlement timing does not automatically determine the contractual due-date treatment of an invoice. The commercial agreement and applicable law may define relevant payment terms. The bank should avoid inventing a universal rule that clicking pay before midnight satisfies every B2B invoice. The service should display its actual processing commitment and preserve evidence of the relevant events.
A payment that is later returned or otherwise adjusted must update the receivables workflow through a controlled process. The invoice may need to show an outstanding amount again, while any independent commercial credit remains valid. The original invoice and payment history should not be deleted. They explain why the account changed.
The practical test is whether the portal can answer two separate questions: what happened to the invoice, and what happened to the money? If it can answer only one, it should not imply that it has complete end-to-end evidence for the other.
A payment instruction can outlive the invoice screen
Suppose the buyer approves a payment and the portal sends it to a bank service. Before the bank response arrives, a user marks the invoice disputed. The application must determine whether the payment is still a draft, accepted for future execution or already completed. Changing the invoice status cannot be assumed to change the external instruction.
The correct response depends on the last confirmed payment state. A cancellable draft can be withdrawn through the supported process. An accepted instruction may require a bank inquiry or cancellation request with no guaranteed outcome. A completed payment may require a later credit or refund arrangement. The portal should show those dependencies instead of presenting a single undo action that promises more than the bank can deliver.
The reverse situation also occurs: the bank rejects the payment, but the invoice remains commercially approved. The approval should remain available while the buyer arranges a supported replacement. Requiring the supplier to issue another invoice merely because funding failed could create duplicate obligations and unnecessary work.
A payment covering several invoices makes the dependency more complex. A dispute on one invoice should not automatically cancel unrelated approved payments unless the actual instruction and customer decision require that treatment. The system should preserve the batch allocation and let authorized users assess the available options.
These cases show why invoice and payment objects need separate lifecycles. They remain linked through references and amount allocations, but neither can safely be represented as a single mutable field on the other. The distinction supports accurate cancellation, replacement and customer communication.
10. Remittance and cash application back to the ERP
EIPP can improve cash application by preserving invoice references through approval and payment selection. When the buyer chooses several invoices, the platform already knows the intended allocation. That allocation should travel through the supported remittance channel and remain connected to the payment reference. The bank receipt can then be matched with less manual reconstruction.
The supplier's ERP needs a reliable update, not merely a portal badge. Depending on the architecture, the portal may send payment advice, proposed application or confirmed application information. The service should specify which event it supplies and what the ERP must validate before posting. A payment advice remains distinct from bank evidence of receipt.
For the $28,500 invoice, suppose the buyer approves $27,000 and disputes $1,500. If it pays $27,000, the remittance should identify the partial allocation and disputed remainder. The portal should not mark the invoice fully paid because the selected payment completed. The supplier can apply cash and continue the commercial case for the remaining amount.
A credit note issued before payment should be reflected in the buyer's selected amount and the supplier's open receivable. If it is issued after payment, it may create a customer credit or another supported treatment. The portal should preserve the timing and relationship so the ERP does not apply both a reduced payment and an unrelated duplicate credit.
Close the acknowledgment loop
An ERP import can reject an otherwise valid portal event because of a closed period, inactive customer or missing reference. The portal should retain the failed application and expose the exception. It should not keep presenting 'posted to ERP' based only on successful file transmission.
Stable identifiers help distinguish a retransmitted event from a new payment. A provider may resend a message after losing the ERP acknowledgment. The ERP should recognize the original application under the agreed interface and return its existing result. A new transport identifier should not create another cash receipt for the same bank movement.
The supplier may also receive payments outside the portal. A buyer can pay through its own bank using the invoice reference without clicking the portal's payment option. The service should support an agreed way to reconcile that external receipt and update the invoice. Otherwise the portal can continue requesting payment for an obligation already satisfied outside its own channel.
A unified receivables view should preserve the source of each event. Portal-originated payments, externally reported receipts and manual adjustments should remain distinguishable in the audit trail. This supports investigation and prevents an operator's manual 'paid' action from masquerading as a bank-confirmed financial event.
Chapter 43's cash-application controls still apply. EIPP improves the quality and continuity of the information, but it does not eliminate deductions, overpayments, missing bank evidence or ERP exceptions. The strongest integration uses the earlier invoice context to make those cases easier to resolve without changing the meaning of settlement or accounting.
11. Credits, rejections and duplicate invoices
An invoice rejection can occur at technical validation, profile validation or business review. The response should identify which stage failed and what the sender can do. A malformed document needs a different repair from an unrecognized purchase order or a disputed service charge. Combining all three into 'payment rejected' sends the supplier to the wrong team.
A corrected submission should preserve its relationship to the original. Depending on the agreed process, the supplier may resend a corrected document, issue a replacement or use a credit-and-rebill procedure. The platform must follow the actual business and accounting requirements. It should not prescribe silent editing as the universal solution.
Duplicate prevention should use both transport and commercial context. A repeated message can be detected by its exchange identity. A duplicate invoice may arrive through different channels with different message identifiers. The buyer should compare the supplier entity, invoice reference and relevant document attributes under its policy. The same numeric invoice reference from two unrelated suppliers is not necessarily a duplicate.
A supplier may submit through a portal and email a copy to a buyer contact. The buyer should avoid entering both as separate obligations. The supplier's communications should make clear when an attachment is a copy of an already submitted invoice. Better channel governance reduces duplicate risk before it reaches payment approval.
The diagram distinguishes transport failure, validation rejection, commercial dispute and a payment already in progress. Corrections preserve document history. A credit note or cancellation changes the commercial record according to the approved process; a completed payment requires separate financial handling where a refund or recovery is needed.
Credit notes are commercial documents
A credit note can reduce an amount owed under the applicable accounting and business treatment. It does not, by itself, instruct a bank to refund money. If the invoice remains unpaid, the credit may reduce the future payment. If it was already paid, the supplier may need to retain a customer credit or make an authorized refund. The portal should make that distinction explicit.
A credit should identify the relevant invoice or relationship sufficiently for both parties to apply it correctly. An unallocated credit can create the same matching problems as an unexplained payment. If a buyer nets it against another invoice, the remittance and supplier policy should support that allocation.
A dispute should not disappear when a technical document is replaced. The buyer and supplier may still need to resolve whether the original charge was valid. The portal should carry forward the relevant case and evidence rather than treat the replacement as a completely unrelated clean invoice with no history.
Payment initiation creates another boundary. If a buyer releases payment and the supplier then issues a credit, the systems should establish whether the original payment can still be changed. A document update cannot be assumed to stop a bank instruction already accepted. The responsible teams may need to complete the payment and handle the resulting credit or refund separately.
Exception closure should include both parties' records where the service supports that visibility. A supplier's corrected invoice is not fully resolved if the buyer still sees the rejected version as the only active document. A completed refund is not reflected correctly if the portal continues to show an unapplied credit. The lifecycle needs coherent updates across the connected systems.
One correction should not create two active receivables
The supplier discovers the wrong buyer entity on an issued invoice. Under the agreed accounting process, it prepares a supported correction and submits the appropriate document. The ERP and portal should agree which obligation remains active and how the original was treated. Merely uploading a new PDF while leaving both invoice records collectible creates duplicate receivables.
The buyer's system needs the same relationship. It may have rejected the original before recording a payable, or it may already have entered it and require a credit or cancellation treatment. The supplier should not assume that the same correction action fits both states. The parties need the actual processing evidence and agreed document procedure.
A correction can also arrive after a payment request was generated. The request should be updated, cancelled or otherwise handled through the supported service so it does not continue asking for the old amount. If the payer already acted, the payment status must be established separately. The new invoice version is not evidence that the earlier financial instruction disappeared.
Reports should show the active invoice population and the history of superseded or credited documents. A dashboard that counts every version as a new sale can overstate receivables and distort performance measures. Conversely, hiding old versions entirely prevents users from explaining why a buyer paid an earlier amount.
The service should test these corrections before launch with the customer's actual ERP and buyer workflow. A clean document exchange proves little about whether both ledgers treat the corrected obligation consistently. That accounting agreement is essential to a credible EIPP service.
12. Security, fraud and separation of authority
EIPP combines commercially sensitive information with actions that can influence payments. Attackers may try to alter collection details, submit false invoices, take over an administrator account or manipulate approval evidence. Controls should protect those business actions as well as the network connection.
Strong authentication and appropriate access reduce account-takeover risk, but they do not establish that every action by an authenticated user is legitimate. The platform should enforce role boundaries and review sensitive changes. A user with authority to upload invoices may not have authority to change the supplier's bank account or approve a buyer's payment.
Bank-detail changes deserve independent verification through an established process. A fraudster may use a real supplier account or a convincing document to request redirection. The FBI's business-email-compromise guidance supports verification of changes to payment procedures and account information. The service should record the verification evidence and effective date, not merely the fact that a form was submitted.
Document integrity matters too. The human-readable invoice and structured data should agree on amount, payee and references. If a PDF shows one account while the structured payment field identifies another, the system should not silently choose one. It should follow a defined validation and escalation process using verified master data and the actual payment arrangement.
Protect the approval trail
Approvals should bind to the document version and amount reviewed. If an invoice changes materially, the workflow should determine whether prior approval remains valid under the buyer's policy. Reusing an approval from a lower amount for a later higher amount can bypass the intended control even when every user login is legitimate.
Attachments and free-text comments can carry malicious content or misleading instructions. Handle them through approved security controls and do not allow embedded instructions to change system configuration or payment authority. The platform should distinguish user-provided business data from trusted operating rules.
Payment sanctions and fraud controls remain part of the actual banking service. A document network's member validation is not a substitute for the bank's applicable customer and transaction controls. Conversely, a bank's payment screening does not certify the legitimacy of every invoice line. The two processes address different risks and should exchange relevant information without claiming identical coverage.
Audit history should capture sensitive changes, approvals, submissions and payment handoffs. Access to that history should itself be controlled. Investigators need enough information to reconstruct who acted, for which entity and on which version, while ordinary users should not receive unnecessary access to other parties' commercial or personal information.
Incident response should coordinate document and payment actions. If compromised credentials changed future collection instructions, the bank and supplier need to identify affected invoices and any payments already released. Restoring the profile is only the first repair. Pending requests, cached instructions and buyer communications may also need correction through verified channels.
13. Operating calendars, service commitments and resilience
An invoice portal can accept submissions outside business hours while the buyer's approval team works a narrower schedule. A document network may exchange messages continuously while a chosen payment method follows its own calendar. The service should describe those differences rather than advertise always-available invoice submission as always-immediate payment.
A supplier needs to know when the invoice was accepted into the relevant process and what response to expect. Internal targets for validation or review should be labeled as service commitments or operating goals, not payment-network rules. A late invoice acknowledgment and a late bank settlement require different escalation paths.
For a concrete official example, the US Treasury's Invoice Processing Platform supports government invoicing from purchase order through payment notification. Its vendor information describes electronic submission and invoice-status access. IPP illustrates how a portal can connect commercial documents and payment information; it should not be described as a new interbank settlement rail or as a universal portal used for all US business invoices.
The bank should avoid quoting adoption counts or platform-specific availability promises unless they are relevant and verified. For implementation, the more useful question is whether this customer's counterparties and required workflows are supported. A large network does not guarantee that a particular buyer will approve an incomplete invoice promptly.
Recover without duplicating obligations
If a portal fails after the supplier submits an invoice, the recovery process should determine whether the original document was accepted. Resubmitting with a new invoice number can create a second obligation. The service should preserve the original identity and use the agreed inquiry or retry procedure.
If the buyer's ERP is unavailable, the receiving provider may hold documents pending delivery. The supplier should see the actual state, and the buyer should receive a complete population after recovery. A provider acknowledgment should not be upgraded to buyer acceptance merely because the downstream system is temporarily unreachable.
Payment outages require separate handling. An invoice can remain approved while payment initiation is unavailable. The buyer may use an agreed alternate method, but the portal should mark and reconcile that external instruction so a queued payment does not later execute as well. Recovery should check the original payment state before releasing deferred instructions.
Operational reports should identify invoices missing expected responses, rejected documents awaiting correction, approved invoices awaiting payment action and payments awaiting bank evidence or application. A single overdue count is less useful because it mixes tasks owned by different participants. Aging should retain the original relevant event rather than reset every time a case changes status.
Resilience testing should include provider outages, expired access, unavailable corporate feeds and lost acknowledgments. The bank should verify that the recovered process preserves document identity, approval history and payment references. A platform that resumes accepting new invoices while losing the unresolved earlier population has not completed recovery.
Keep a usable record when a provider relationship ends
A supplier may change portal or exchange providers while invoices remain open. The exit plan should preserve issued documents, responses, approvals, payment references and unresolved cases needed for the continuing business relationship. A downloadable list of invoice totals is insufficient if it omits the evidence explaining disputed or partly paid items.
The supplier and buyer should know where to send new documents after the transition and how older documents will be handled. A provider change should not create duplicate active submission routes without controls. Where an endpoint or business identifier changes, the parties should follow the network and provider's actual maintenance process and verify the resulting destination.
Payment credentials and collection instructions require separate assessment. Moving document exchange to another provider does not automatically move a banking arrangement or authorize a new debit originator. The implementation should identify which financial relationships remain in place and which require approved changes. A new portal logo should not conceal a new account or authority model.
The old provider may still receive late acknowledgments or payment information for earlier documents. The exit process should define how those events reach the current operating team and how they are reconciled. Otherwise the supplier can lose visibility precisely where an unresolved invoice needs the most attention.
Users should retain appropriate access to historical evidence without keeping unnecessary ability to submit new documents or change financial settings. Read-only history and active operating authority are different needs. The bank should apply the actual retention, security and contractual requirements rather than leave all old users fully enabled indefinitely.
A controlled exit test can export a representative disputed invoice, a credit note, a partly paid invoice and an externally paid item. Confirm that the receiving team can reconstruct each status and its supporting evidence. This is a practical way to assess portability without claiming that every provider uses an identical data model.
Service metrics should follow the invoice's real journey
Count documents submitted, technically accepted, business-rejected, approved and paid as separate measures with defined populations. An invoice can move through several of those states, so adding the counts together does not produce a meaningful total of business obligations. Reports should identify whether they count documents, versions, events or distinct invoices.
A resend can improve delivery completion without representing another sale. A credit note can reduce an obligation without being a negative payment. A buyer's payment advice can improve forecast visibility without increasing cash. Keeping those measures distinct prevents management dashboards from turning message activity into fictitious financial performance.
For turnaround measures, identify the starting and ending events. Time from supplier submission to access-point acceptance is a technical service measure. Time from buyer receipt to approval reflects a business workflow. Time from authorized payment to confirmed receipt depends on the actual financial service. A single average can be useful only when its definition is clear and its component delays remain visible.
The supplier should be able to use the report to decide what to do next. A missing acknowledgment may require provider investigation; a rejected purchase-order reference needs correction; an approved invoice awaiting a payment date belongs with the buyer's payment process. Reports that identify those owners reduce unnecessary calls to the bank about events the bank has not yet received.
These operating details matter because EIPP spans organizations. The service creates value when it connects their evidence and responsibilities accurately, including during transition and exception handling. It should not merely provide an attractive front end over unresolved handoffs.
14. Implementing the service inside a bank
The bank should start with a representative supplier and buyer journey. Identify the source invoice system, required document profile, access model, approval process, payment methods and ERP application. This map reveals which functions the bank will provide and which remain with partners or customers.
Architecture should preserve separate business objects for invoices, document deliveries, approvals, payment instructions, bank events and applications. One invoice can have several deliveries or payment attempts, and one payment can cover several invoices. A single flat status field cannot represent these relationships reliably. The data model should support them before dashboards and notifications are built.
Integration contracts should define identifiers, event semantics, acknowledgments and corrections. A transport message can be delivered more than once; processing should recognize the underlying event. A later business rejection should not overwrite the evidence that delivery succeeded. Both facts can be true and useful in an investigation.
The bank should obtain current provider and network specifications for production details. Public overviews are useful for understanding roles, but they are insufficient to implement authentication, routing, message validation or certification. This chapter deliberately avoids unverified endpoints, payload fields and mandatory processing windows. Those details must be established during the actual integration.
Pilot the complete financial relationship
A pilot should include invoice creation, technical acceptance, buyer rejection, correction, approval, payment initiation, bank reporting and ERP application. It should also include an invoice paid outside the portal and a credit issued after payment. These cases establish whether the platform can maintain a coherent record when the happy path changes.
Finance should review document and payment accounting together. Does the supplier ERP contain the same active invoice version? Does the buyer avoid duplicate obligations? Does a credit note affect the correct balance? Does the payment reference survive into remittance? The bank should not declare the pilot complete based only on a successfully exchanged XML file.
Customer training should use the actual status labels and correction procedures. Suppliers need to know when to repair a document, contact the buyer's approval team or investigate a bank payment. Buyers need to know which action approves an invoice and which action releases money. Clear training reduces support requests caused by ambiguous portal language.
Vendor oversight should include interoperability changes, evidence access and incident recovery. A network profile change can affect document validation; a payment-provider change can affect status and remittance fields. The bank should assess those changes against the complete customer journey and test affected interfaces before release.
Success should be measured through fewer unresolved invoice problems, accurate payment references and reconciled application, not only portal logins or documents transmitted. The strongest service makes the commercial and financial evidence easier to use while retaining each participant's authority and responsibility.
Notifications should follow the same event definitions as the portal. A supplier email announcing approval should not be triggered by technical acceptance alone. A buyer reminder should use the active document and current outstanding amount. If a payment arrives through another channel, the notification process needs the reconciled update before sending another demand. The implementation should test queued messages during corrections and partial payments, because a correct portal can still produce misleading communications from stale notification data. A message should help the recipient take the next useful action, with a reference that leads back to the relevant invoice history.
15. Worked cases and implementation decisions
The following cases use the fictional maintenance supplier and manufacturing buyer. Each tests a boundary between document handling, commercial decision and financial execution. The amounts and workflows illustrate design choices rather than mandatory US processing rules.
Delivered but not approved
The supplier submits the $28,500 invoice and receives an access-point delivery acknowledgment. The buyer rejects the purchase-order reference. The portal should show successful document exchange and the business rejection, with a correction path. It should not say that a payment failed, because no payment instruction has yet been established.
The supplier should confirm the correct reference through the trading relationship and follow the agreed correction process. The buyer should receive the corrected document linked to the original history. Once the buyer validates and approves it, the payment stage can begin. The original delivery timestamp remains useful evidence without being treated as approval.
Approved amount differs from the invoice
The buyer approves $27,000 and disputes $1,500 of the $28,500 invoice. The portal should preserve both amounts and the reason. If the buyer pays $27,000, the supplier should receive remittance identifying the partial allocation. The invoice should remain open for the supported residual or credit treatment.
If the supplier later agrees to the deduction, an approved credit can clear the remaining amount. If it disagrees, the commercial case continues. The bank should not adjust the received payment to match the original invoice or mark the dispute resolved simply because settlement completed.
A new bank account appears on an attachment
An invoice attachment instructs the buyer to use a different collection account. The structured invoice and verified supplier master still show the established account. The buyer should stop and use its controlled verification process. The attachment is not sufficient authority to change the destination.
The bank or provider should preserve the conflicting evidence and involve the appropriate fraud or customer team. If the change is legitimate, it should be approved and applied with a clear effective scope. If it is fraudulent, affected pending instructions and communications may need correction. Merely deleting the attachment does not establish that no payment was redirected.
A payment occurs outside the portal
The buyer pays through its own bank and sends the invoice reference. The supplier receives the funds, but the portal still shows payment due because no portal payment was initiated. The service should reconcile the external receipt through its supported process and update the invoice based on evidence.
The buyer should not be required to make another payment through the portal to clear a display problem. The supplier's ERP and portal need a controlled application update. Any queued reminder or payment request should reflect the corrected balance so the original receipt does not lead to a duplicate collection.
A credit arrives after release
The supplier issues a $1,500 credit after the buyer has released the full payment. The invoice workflow should not assume that the bank instruction can still be changed. The buyer and supplier need the actual payment status and the supported next action.
If the payment completes, the credit may require a customer-credit or refund treatment under the agreement. Any refund is a separate authorized financial transaction. The original invoice, credit, payment and refund should remain linked so both parties can reconcile the outcome.
For each case, ask which document version is active, what the buyer approved, what payment was authorized, what bank evidence exists and what the supplier applied. Those questions expose most EIPP inconsistencies before they become customer disputes or accounting errors.
Reconcile an invoice with payment outside the network
A supplier issues two invoices for $12,000 and $8,000 through an exchange network. The buyer approves both and pays $20,000 through its own bank, outside the portal's initiation feature. The supplier's bank reports the receipt and the remittance identifies both invoices. The service should apply or propose the supported allocations and update the portal through its agreed integration.
The document network has not settled $20,000. It delivered the invoices and may have carried related statuses. The actual bank payment supplied the funds, while the ERP application reduced the receivables. The reconciliation should preserve all three references so each participant can explain its part.
If the remittance instead identifies only the $12,000 invoice, the remaining $8,000 requires clarification or another supported allocation policy. The portal should not infer that every displayed invoice was paid merely because the combined total matches. A buyer can have other obligations or intended advances of the same amount.
If the bank receipt later receives a supported financial adjustment, the application process should identify which allocations are affected. The invoice delivery and approval history remain true even if the financial outcome changes. Keeping those records intact lets the supplier distinguish a new payment problem from an old document problem.
16. Role checklist and learning closure
Product should explain whether the service is a supplier portal, buyer portal, document-network connection or a combination, and which payment capabilities it actually provides. It should distinguish document delivery from buyer approval and financial execution.
Technology should preserve document versions, exchange identities, approvals and payment references through retries and corrections. Operations should route technical rejects, commercial disputes and payment exceptions to the right owners. Finance should connect invoice and credit records to received funds and ERP application without treating a document as cash.
Risk teams should protect sensitive master-data changes and payment authority as well as access to the portal. Customer teams should explain exactly what a status proves and what action remains. A useful EIPP service reduces uncertainty by making the evidence clearer.
Chapter 45 turns to pay-by-bank, account linking and account-to-account collections. It examines the permissions and banking mechanisms behind a payment option that can appear inside these portals, while keeping data access, payment authorization and settlement distinct.
Authoritative references
Sources checked on October 5, 2026. Network profiles, access-point requirements and payment interfaces must be confirmed from current participant documentation. The cited UBL standard and the DBNAlliance's published supported profile are distinct; do not substitute versions without agreement.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.