<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=3960532&amp;fmt=gif">
PredictAP Blog

Closing the Loop: What a Truly Optimized Invoice-to-Payment Process Looks Like

Most finance teams have solved pieces of the AP puzzle. They've got a decent ERP. They have approval workflows. Maybe they've even automated some payments. But the gaps between those pieces is where real pain lives.

In a recent webinar, treasury leaders from CBRE and Realty Income joined PredictAP founder and CEO David Stifter and Kyriba's Andrew Blair to walk through how they tackled the full invoice-to-payment cycle end to end. It was an insightful conversation about the operational complexity that grows faster than most teams anticipate, and what it takes to get ahead of it.

The webinar recording is available on demand here.

Where It All Started: Growth Outpacing Operations

Stifter opened with a story that resonated. At Colony Capital (now DigitalBridge), the firm had grown from a single private equity fund into a multi-entity global operation β€” public companies, private funds, sidecar vehicles, a dozen ERPs, and payment processes that still relied on paper wire packets and manual bank portal logins.

"We just threw bodies at the problem," he said. "Which is not uncommon. The business grows and you hire someone to walk around with the wire packet and get a signature. It works, but it doesn't scale, and it creates a lot of risk."

The team started mapping where time was actually being spent. Two observations surfaced quickly:

Duplicate data entry was everywhere. Someone would key information into a system to create an approval, and someone else would re-key that same information into a bank portal to execute the transaction. Every re-keying is a chance for errors, timing mismatches, and reconciliation headaches.

The coding problem was harder than it looked. Extracting invoice number, total, and due date is easy. Knowing how to split that invoice across 37 entities β€” accounting for what's recoverable, what goes to which fund, which building's budget β€” that's a different problem entirely. It lives in people's heads, not in any system.

The Six Recurring Problems (No Matter the Company)

Omair Asad, VP of Treasury at Realty Income, laid out the complexity factors that seem to appear at every firm at scale. These aren't exotic edge cases β€” they're table stakes challenges for any growing real estate or multi-entity finance operation:

1. Entity proliferation. The bigger the company, the more legal entities. Each one needs its own bank accounts, its own financials, its own covenant-compliance reporting. What starts as a manageable chart of accounts becomes a sprawl.

2. Global complexity. Once you expand beyond one country, you're managing multiple currencies, regional tax obligations, local payment formats, and now β€” with Europe's push toward e-invoicing β€” new compliance requirements layered on top.

3. Granular coding accuracy. When invoice coding happens at the property or entity level, the margin for error compounds. A miscoded invoice creates reclassification work at month-end that slows the close.

4. Allocations and intercompany. When one entity pays on behalf of another, or when a single invoice needs to be split across a fund, a sidecar, and a balance sheet, the allocation logic is intricate and often tribal knowledge.

5. Cash visibility across banks. Before implementing a treasury system, teams were logging into each bank portal individually. With many unique banks across multiple currencies, that's a blind spot for cash positioning.

6. High-stakes payment deadlines. Taxes. Insurance. Acquisition fundings. Miss one of these and create a crisis of confidence with internal stakeholders, investors, and lenders.

The Problem at the Front of the Cycle: Invoice Coding

Seven or eight years ago, the tools available for invoice processing leaned heavily on OCR to capture the obvious fields: vendor name, amount, due date. Some used RPA, building rule-based templates to route and code invoices. But rule-based systems break when the rules don't match reality. "What was on the paper doesn't necessarily match the reality of how it's working," Stifter explained.

The deeper issue was institutional knowledge loss. When key people who understood the nuances of entity structures, recovery arrangements, and intercompany relationships left the firm, the coding accuracy fell apart. No platform or process had captured what those people knew.

What makes AI a better fit here is the nature of the data itself. Invoices from the same vendor tend to follow patterns. Coding decisions produce a feedback loop: when someone corrects a miscoded invoice, that correction is a training signal. Over time, the model learns not just what's on the invoice, but what the firm's own history says it should mean.

Trisha Koyanagi, Global Treasury Leader at CBRE, described the practical outcome: her team is no longer making judgment calls on entity selection and GL coding for every invoice. They're reviewing the AI's suggestions and correcting the exceptions. "The AI agent helps to take away some of the judgment calls, so all we're really doing is doing the review piece."

And when someone within the workflow does correct the suggestion? The model learns from it. "If they do change anything, the bot actually learns from what it did wrong, remembers it, and hopefully the next time it sees that invoice it fixes it on its own," Koyanagi said.

The Middle: Workflow, Approvals, and Connecting to Payment

Once invoices are coded and approved, the next problem is getting that information to a payment system without re-keying it.

At both CBRE and Realty Income, the architecture follows a similar pattern: PredictAP ingests the invoice and auto-generates the coding, exceptions get reviewed and corrected in a workflow, and the approved invoice lands in Yardi (their ERP). From there, Kyriba picks up the payment instruction automatically.

A few things stand out about how this works in practice:

No manual re-entry at the payment stage. Whatever the ERP transmits goes to Kyriba unchanged. "We can only delete or approve in Kyriba," Koyanagi noted. This isn't just efficiency; it's an internal control. The payment that goes to the bank is exactly what was approved in the ERP, full stop. That traceability matters enormously when talking to internal auditors or investors.

Bank-agnostic connectivity. Kyriba handles the file format translation for each bank and payment type, such as ACH, wire, EFT, international transfers. Teams don't need to maintain different payment formats for different banks. That complexity is abstracted away.

Fraud detection as a built-in checkpoint. Before payments execute, Kyriba runs them against rule structures looking for anomalies like deviations from prior payment patterns, unusual amounts, or first-time payees. This acts as an additional layer of control without adding manual steps.

The Back of the Loop: Reconciliation

Here's where the "close the loop" framing really earns its name.

In the old model, bank reconciliation was a multi-day process. Someone would log into each bank portal, download statements, manually match transactions, and reconcile exceptions one by one. At month-end, with a tight close timeline, this bottleneck was brutal.

In the new model, after a payment executes, the bank sends a confirmation back to Kyriba. Kyriba pushes that confirmation back into the ERP, which auto-reconciles the transaction. The loop closes.

Koyanagi’s team saw the most dramatic change here: "A bank rec that used to take five days now only takes not even half an hour to an hour to complete."

The Broader Philosophy: Upstream and Downstream Thinking

One of the more practical insights from the conversation was about how to approach process improvement in the first place.

It's tempting to fix problems standalone β€” get a better approval workflow, or clean up the payment execution, or automate bank recs β€” without thinking about how each piece connects to the others. Stifter pushed back on that approach:

"You don't want to solve all problems at once, but what you need to do is at least have a plan and a path that gets each piece you work on to help not just this discrete problem but those downstream and upstream from the issue."

The corollary: look for solutions that don't require ripping out and replacing the core ERP. Both PredictAP and Kyriba take an ERP-agnostic approach β€” they layer on top of existing systems (Yardi, MRI, whatever's in place) rather than requiring migration. As Stifter summarized: "Effective technology doesn't require a massive rip-out and re-engineering. It's enhancing what's there."

This also has practical implications for adoption. Realty Income, for example, started with AP payments through Kyriba and expanded over time to handle intercompany transfers, distributions to investors, and fund-level cash management. They didn't need a perfect end-state design before they started. They started with a clear direction and built toward it incrementally.

Key Takeaways

The coding problem is underrated. Capturing invoice totals is easy. Applying accurate, entity-level GL coding at scale, especially across complex fund structures, is where most teams lose control. It's a perfect use case for AI because the underlying patterns exist; they just need to be learned and maintained.

Re-keying data is the enemy. Any time the same data is entered more than once, you've created risk, inefficiency, and a reconciliation problem. The goal is one input that flows through the entire cycle.

Closed-loop reconciliation changes everything. Getting payment confirmations back from the bank and auto-posting them to the ERP eliminates the manual bank rec burden and accelerates close.

ERP-agnostic tools reduce implementation risk. Solutions that layer on top of existing systems rather than requiring replacement are far more likely to actually get deployed and deliver value.

Start with direction, not perfection. Neither CBRE nor Realty Income had a fully optimized process on day one. They identified the highest-pain areas, started there, and built the loop out from those wins.