The AI cash app that broke every competitor convention

Accounts receivable teams at materials distributors process large volumes of incoming payments daily. Each payment arrives with remittance documentation in an inconsistent format, scanned checks, emailed PDFs, bank lockbox files, and uploaded documents, and teams are expected to extract the relevant data, locate the correct open invoices, resolve discrepancies, and post to the ERP. Done manually at scale, this is slow, error-prone, and increasingly unsustainable as transaction volume grows.

Automation tools exist across the market to address this. The problem is that most of them introduce a different kind of friction. Interfaces built years ago and never substantially updated. Workflows that expose system architecture rather than guide a user through a task. Actions buried several levels deep. Processing logic surfaced in the UI as something the user needs to actively manage. The automation exists on paper. The experience of using it is cumbersome enough that AR teams continue doing significant manual work even when a platform is deployed.

A competitive analysis was performed across the major platforms in the AR automation space. The functional coverage across these platforms is broad. The experience of using them is consistently poor in ways that appear to be industry-wide assumptions rather than deliberate choices.

Two patterns emerged from the audit that shaped the entire product direction. The first is how these platforms handle document processing. Most process mailboxes, bank feeds, and SFTP sources on a scheduled interval and surface those sync windows as discrete batches directly in the main UI. This originated as a backend architecture decision and migrated into the product experience until it became an accepted convention. Users adapted, building their day around checking in every few hours, processing whatever accumulated, and moving on. Suppli processes documents in near real time, so there is no periodic batch to manage. Rather than preserve the concept out of familiarity, the product decision was to remove it entirely and communicate that clearly to users. The absence of batches is a feature, not a gap.

The second pattern carried more weight in shaping the design. An industry-standard layout places the remittance document preview on the left side of the screen and the matching controls and payment table on the right. This layout has become so universal that users have internalized it as the natural order of things, a perceived default for how cash application software is supposed to look. It functions as an industry convention. It is also wrong. Users process information following an F-pattern, scanning left to right with priority given to whatever appears first. The remittance document is reference material. It is something users consult, not something they act on. Placing it in the dominant visual position and pushing the action controls to the right is a structural mismatch between where the eye goes and where the work happens.

The design process started with task decomposition, breaking every step in the cash application workflow down to its smallest meaningful unit before touching a single screen layout. What does the reviewer need to see at each moment. What decision follows. What action that decision requires. What happens next. This ground-up approach, building from individual task steps rather than from system capabilities or competitor reference screens, is what made it possible to challenge the assumptions that the audit had surfaced rather than reproduce them.

The layout reversal was the central design decision. The payment matching table and all action controls sit on the left. The remittance document preview sits on the right. For users coming from competing platforms, this initially registers as unfamiliar. The mental model built through years of using those tools assigns a specific visual structure to this type of software, and the Suppli interface does not match it. What the user testing revealed was that the unfamiliarity resolved quickly. Once users worked through the interface, the response was consistent: the flow felt more natural, the progression from left to right aligned with how they were already reading the screen, and the remittance document was where they expected reference material to be rather than where they expected to act. The convention the market had established turned out to be something users had adapted to, not something they preferred.

The review flow is built around a single task at a time. The reviewer addresses one payment, makes any required corrections, confirms, and advances to the next. There are no parallel panels requiring simultaneous attention, no batch-level views to navigate through before reaching actionable items, and no layered submenus holding the controls used on every session. When the AI flags a payment for human review, the reviewer sees the specific field or line item in question, the reason for the flag, and the resolution options available. The exception is surfaced at the correct level of specificity so that acting on it requires a judgment call, not an investigation.

Suppli's existing customers did not have a Suppli cash application tool since it did not exist yet. They were actively using competing platforms in their daily work. This gave the research phase an advantage that is difficult to manufacture: direct access to people who could speak precisely about what existing tools got wrong, which workarounds had become part of their workflow, and what they needed to do their job efficiently. That operational knowledge, collected through structured discovery sessions before any wireframe existed, defined the product strategy and shaped the initial feature set.

Product definition translated this research into a formal specification. The PRD documented the end-to-end processing pipeline, data model, matching logic across multiple key types, exception handling flows, edge case behaviors, and ERP integration architecture. Success metrics were defined alongside functional requirements, establishing the baseline against which the first release would be evaluated.

Prototype development used Lovable to produce a working interface for user testing. Under the lean UX framework, each iteration cycle followed the same structure: present the prototype to users, collect specific feedback against the documented pain points, revise the design, and repeat until the output was ready for developer handoff. AI-assisted UX audit tools contributed to this process, but their role was bounded. They identify heuristic violations and flag accessibility issues efficiently. They do not carry the embedded, day-to-day frustrations that users have quietly worked around for years. That knowledge came from the users themselves, and it was the input that drove the most significant design decisions.

In a product where AI handles the majority of matching invisibly, the user's confidence in the system depends entirely on what the interface communicates about what is happening beneath the surface. A platform that processes accurately but provides no signal about its own performance creates the same anxiety as one that processes poorly. Users have no reliable basis for trust and no clear trigger for when to intervene. Nielsen's visibility of system status heuristic is foundational in this context, not as an abstract principle but as a concrete product requirement.

The dashboard was designed to address this directly. It surfaces real-time statistics across three matching states, full match, partial match, and no match, alongside a historical graph tracking matching rate and AI accuracy over time. When model performance shifts, users see it in the graph before it accumulates into a problem. When a wave of unmatched payments arrives, the dashboard makes it visible immediately. The goal is to ensure that users always have an accurate picture of what the system is handling on its own and what requires their attention, without having to go looking for that information.

The engagement covered the full pre-development phase from idea validation through developer-ready handoff. Deliverables included a competitive analysis and UX audit, structured user research synthesis, a complete PRD covering the end-to-end pipeline, data model, matching logic, exception handling, and ERP integration architecture, and a fully iterated prototype built in Lovable and tested across multiple lean UX cycles with Suppli customers. The first production release was scoped to PDF document upload, 80 percent or higher AI matching accuracy, and multi-page document support.