The Work Behind Faster Supplier Payments

An immediate need within a larger ambition

The organization relied on small independent suppliers to carry out approved work. For those suppliers, waiting for payment could constrain their ability to fund further materials and labor. Inside the organization, people handled incoming invoices and checked information across separate business records before the invoices could proceed.

Suppliers commonly emailed photographs of invoices; some sent PDFs. The submission reached the enterprise, but the information still needed to be extracted, connected to the right work and checked against the conditions for payment.

Our longer-term goal was an app that suppliers could use to capture, validate and submit an invoice. We wanted an initial solution in place within two to three months. To serve that immediate need, we kept email as the submission route and improved the processing behind it.

I defined the vision, architecture and design, including the core data-processing and validation algorithm. My team delivered the solution. The important design responsibility was connecting what arrived from a supplier with what the organization already knew and had authorized.

Make the invoice meaningful in the context of the work

Document extraction turned information from invoice images and PDFs into data that the processing flow could use. That addressed one part of the manual effort. Whether the invoice was eligible to proceed depended on its relationship to approved business records.

The validation logic connected several conditions:

Condition	What the processing needed to establish
The right work	Required identifiers linked the invoice to the work for which payment was being requested.
An eligible submission	The invoice fell within the defined submission window for that work.
An approved amount	The invoice stayed within the approved purchase order. For partial or multiple invoices, the cumulative amount, including the current invoice, could not exceed that limit.
An authorized revision	An amount beyond the original purchasing authorization required an approved revised purchase order and override.
Permission to release payment	The responsible manager had recorded confirmation of the work and authorized payment release.

The cumulative check illustrates why the operating logic mattered. An invoice can look acceptable in isolation while the total of several claims exceeds what was approved. Reading the current document accurately would not resolve that question. The system needed the relevant history and the approved limit together.

These were conditions for a defined processing route. They did not give the automation authority to change purchasing commitments or decide that work was satisfactory.

Keep the work approval where the knowledge resides

The responsible manager inspected the work and recorded the approval needed for payment release. Ideally, that confirmation was already in place when the supplier submitted the invoice.

If it was missing, the automation held the invoice and waited for the manager to update the record. A submitted invoice could not stand in for approval of the work. Faster document handling would have achieved little if the design had quietly bypassed that distinction.

For eligible invoices with the necessary conditions satisfied, the automated path required no further human handling within that route. The supplier still submitted the invoice, and the manager still judged the work. The change was in how the enterprise processed an invoice once those responsibilities had been fulfilled.

This is an authority question that remains relevant beyond conventional automation. The Bounded Autonomy framework examines when a system has permission to act and what must happen when a required condition is absent. That is a useful lens for the experience today; the historical implementation described here was a document-processing and validation workflow.

Choose a useful boundary for the first change

Keeping email was a sequencing decision. It gave us a route for improving invoice processing while the more complete supplier experience remained a separate ambition. Suppliers could continue sending photographs or PDFs, and the team could concentrate on extracting the information and connecting the checks.

That choice carried a tradeoff. We still depended on the information suppliers included in their documents. We had improved the enterprise's ability to process those submissions, while leaving the work of preparing an invoice largely with the supplier.

We also retained the dependency on recorded work approval. Automation could handle the eligible processing path; it could not make an unrecorded business decision disappear. The boundary of the first change was useful precisely because we understood the responsibilities around it.

In operation, I observed eligible invoices moving through processing and payment handling more quickly. I describe that improvement here as a qualitative recollection. This account does not establish a measured processing rate, a savings figure or a bank-settlement service level.

The experience reinforced a practical judgment: a focused intervention can be valuable before the entire future design is in place. Its value depends on whether it addresses a meaningful constraint in the wider operation. The number of steps changed, or the novelty of the technology, tells a leader much less.

The operating work behind the technology

Looking back, I see three connected responsibilities in this design.

Technology & data made the invoice usable and connected it to the records needed for a decision. Adaptation shaped the work around that capability: retain a familiar submission route, address an immediate constraint and sequence the fuller supplier experience. Control turned purchasing limits and payment authority into conditions the processing had to respect, while keeping judgment about completed work with the responsible manager.

That experience helps explain why I focus on adaptation and control. Better extraction would have created capacity. Its operating value depended on the surrounding responsibilities, records and decisions.

BCG's September 2026 article, The Formula for Agentic AI Value, describes a 10–20–70 model for allocating transformation effort: 10% to algorithms, 20% to technology and data, and 70% to people, organization and processes. It is a useful reference for the attention leaders need to give the surrounding operation. These are not measured percentages from this initiative, nor percentages of its value.

Adaptation and control are my lens for interpreting that operating work. They depend on technical design as well as changes to how people work. A more accurate model alone cannot establish that work was acceptable, that purchasing authority remains available or that payment release has been approved.

What I would build today

Today, I would also reconsider how the invoice is created. The organization already holds information about the supplier, the approved work and the purchasing authorization. I would use that context to prepare a form specific to the work and send the supplier a link.

The form would carry forward the information already known and ask for what was still needed. A supplier who preferred not to type could use a short voice conversation or chat on a phone to prepare the invoice. The supplier would then review the details, correct anything necessary and submit it.

AI would help turn the supplier's voice or chat into a draft submission using the relevant work context. It would not decide that the work was satisfactory or authorize payment. Those responsibilities would remain with the manager, and the recorded conditions would still determine whether processing could proceed.

This is a proposed next design. It was not part of the original implementation. Its purpose would be to reduce avoidable entry and correction at the point where the invoice takes shape. The supplier's review would remain explicit, and submission would still be subject to the purchasing limits, work approval and payment-release conditions.

The expected benefit would be easier submission and faster progression of a valid invoice. I would test that expectation by looking at supplier effort, missing or corrected information, time spent waiting for approval, and the time from submission to the relevant payment milestone. Those observations would help distinguish a better interface from a better operating outcome.

The first solution concentrated on making incoming documents usable. The next opportunity I see is to use known context earlier, so the supplier has less work to do before submitting one.

Let value determine how far the change needs to go

The broader lesson is about choosing scope. Leaders need enough understanding of the whole operation to know which focused change is worth making. That includes the people who supply information, the decisions that authorize action and the work that continues after an automated step finishes.

A narrow change deserves investment when it improves the outcome that matters. It needs reconsideration when it simply moves the queue, creates extra checking elsewhere or makes a local measure look better while the supplier still waits.

This is the relationship between the Value Lens and Operating Model Redesign: choose the problem by its consequences, then understand the connected work well enough to intervene deliberately. The investment can be focused even when the reasoning must be broad.

For an existing automation estate, Modernize the Automation You Already Have develops the corresponding review: preserve useful capabilities, address operating weaknesses and require a reason for each additional technology choice. In this experience, the immediate opportunity was within the process already in use. The next opportunity would begin earlier, with the supplier creating the invoice.