Finance tooling cycles between bundling and unbundling. The unbundling cycle is currently active, with capabilities that used to require dedicated tools moving into the surfaces customers already use. Embedded payments, embedded lending, embedded insurance are all live trends. Embedded AP is the next chapter. The version that matters is structural, not cosmetic. The version that does not matter is a payments button bolted onto an existing tool.
The bundling cycle in finance tooling
Finance tooling has cycled between bundling and unbundling for forty years. Bundling produces large, integrated suites that combine accounting, AP, AR, treasury and reporting inside a single platform. Unbundling produces specialist tools, each best-in-class for a defined function. The category is currently unbundling on the analytical and operational layers, but re-bundling at the surface layer through embedded delivery.
The shift matters because it changes where the customer encounters the capability. In the unbundled world, the customer goes to the specialist tool for the function. In the embedded world, the function comes to the customer inside the tool they were already using.
Why AP is moving toward embedded delivery
Three pulls are operating simultaneously.
ERPs as host. Mid-market ERPs are exposing surface area to third-party capabilities through APIs and marketplace integrations. AP capability that previously lived in a separate tool is being pulled inside the ERP surface, with the heavy lifting done by a network beneath. The architectural rationale sits in ERP-agnostic AP.
Marketplaces as host. B2B marketplaces (procurement, ecommerce, vertical-specific marketplaces) are embedding AP capability so the buyer's payable flow does not break when an invoice originates inside the marketplace.
Vertical SaaS as host. Practice management tools, project management tools, agency tools and others increasingly host AP capability so the user does not have to leave the workflow to manage supplier payments.
In each case, the host is not building AP. The host is consuming an embedded AP capability and presenting it inside their surface.
What real embedded AP looks like
Three layers move into the host.
Identity. The supplier verification, beneficial ownership, sanctions screening and behavioural baseline that sit inside an AP network are surfaced through the host. The user sees verified suppliers in the host's interface. They do not need to leave the host to verify. The data layer is the supplier identity graph.
Behaviour. The supplier's payment behaviour and exception profile are accessible inside the host. The user can read the supplier's status and risk before they approve a payment, inside the workflow they were already using. Supplier trust scoring is what feeds this layer.
Controls. The bank-detail change workflow, exception management, four-eyes approval and audit trail run inside the host but draw on the network for the data and the rule engine. The host is the surface. The network is the substrate. This is the operational expression of why supplier verification and payment behaviour are converging.
None of this is visible to the user as embedded AP. The user experiences a host that handles supplier payments well. The infrastructure beneath is what makes that experience possible.
The risk of cosmetic embedding
The risk in any embedded trend is that the host implements the visible surface without the underlying capability. The user gets a payments button. The button initiates a transfer. The supplier identity, behavioural verification and exception handling are missing.
Cosmetic embedding looks like embedded AP from the user's side until something goes wrong. The user assumes the host has verified the supplier. The host has not. The fraud or sanctions exposure lives inside the host's interface, where the user did not know to look for it.
The diagnostic is straightforward. Ask the host where the supplier verification comes from. Ask whether the bank-detail change workflow uses the host's data or a network's. Ask whether the supplier's behavioural baseline is current or historical. The three answers separate real embedded AP from cosmetic embedded AP cleanly.
What partners should look for
For platforms considering embedding AP, three criteria filter the field.
Network depth. The supplier coverage on the network determines how many of the platform's customers' suppliers will be verified out of the box. Thin networks produce thin embedded experience.
API surface. The embedded experience is only as good as the API allows. Look for verification status, behavioural signals, exception workflow and audit trail in the API. Anything less than full surface area limits what the platform can build.
Governance. The data flowing into the platform's environment carries provenance, freshness and consent expectations. The network's governance posture should be readable to the platform's own customers, not opaque.
Where this is going
The destination of the embedded trend is that AP capability becomes infrastructure. The customer does not buy AP. The customer buys an ERP, a marketplace, a vertical SaaS, and the AP capability is part of the experience. The specialist tool category does not disappear, but it shrinks toward the substrate, where the network operates.
This is good for buyers, suppliers and the category. It is bad for vendors selling AP as a feature rather than as infrastructure. The cycle has happened in payments, in lending and in insurance. AP is the same shape, on a slightly later clock.
.jpg)