Case Study: How AI Found 264 Lapsed Accounts Hidden in ERP Data

Verified result

Yes. In Wallai's client-de-identified manufacturing example, an AI-supported system surfaced 264 lapsed accounts from six years of ERP sales data and classified 804 accounts by revenue trajectory.^[1]

The public proof page reports that the manufacturer had the sales history in its ERP but lacked a usable view of customer revenue trajectories.^[1]

Wallai built an AI-supported customer-intelligence system that:

• classified 804 accounts by revenue trajectory;
• surfaced 264 lapsed accounts;
• showed that those lapsed accounts represented 33% of the account base when 264 divided by 804 is rounded to the nearest whole percent;
• identified the largest cited previously annual account as having moved from $67,000 per year to zero;
• refreshed the classifications automatically every quarter.^[1]

The public case does not state that every lapsed account was recoverable. It does not report $67,000 in recovered revenue or claim a total revenue win. The documented result is the classification and surfacing of customer-account changes for business review.

The business problem

The manufacturer already owned the sales history. The problem was access to the commercial meaning inside it.

Wallai's public description states:

“Six years of sales data sat in an ERP that couldn't answer a single question about the business.”^[1]

Transactional records can show what was ordered and invoiced. Commercial teams often need a different view: which accounts are growing, declining, inactive, or lapsed, and which changes deserve investigation.

In this engagement, the missing view meant a large group of inactive accounts had not been surfaced as a defined commercial segment.

What Wallai built

The public proof page describes the build as an AI system that classified 804 accounts by revenue trajectory and refreshed automatically every quarter.^[1]

The published information establishes:

• the source period: six years of sales data;
• the population: 804 accounts;
• the analytical output: revenue-trajectory classifications;
• the key finding: 264 lapsed accounts;
• the refresh cadence: quarterly.

The public page does not disclose the client's identity, ERP vendor, fields, classification thresholds, models, prompts, integration design, security architecture, or account-level records. Those details should not be invented.

Why the 33% figure is accurate

The published figures are 264 lapsed accounts out of 804 accounts.

264 ÷ 804 × 100 = 32.8358...%

Rounded to the nearest whole percent, that is 33%.

This percentage describes the share of accounts classified as lapsed under the project's method. It does not establish the share of company revenue represented by those accounts.

What the result made visible

The system converted a large set of transaction records into an account-level view that could be reviewed by the business.

That type of view can support questions such as:

• Is the account truly lost, or was its activity moved, renamed, merged, or recorded differently?
• Did a distributor, product change, territory change, or service issue affect the pattern?
• Is the account still in the target market?
• Who owns the relationship?
• Is outreach appropriate?
• What action, if any, should be recorded?

These are recommended review questions. The public case page does not report the client's answers or actions.

What this case proves

The public evidence supports a narrow conclusion:

Existing ERP sales data can contain customer-trajectory signals that become more usable when accounts are systematically classified and refreshed.

It also demonstrates that an AI project does not need to begin with replacing the ERP. In this case, the documented value came from creating a customer-intelligence layer using data the business already had.^[1]

What this case does not prove

A credible case study should separate the documented result from possible future value.

The public evidence does not establish that:

• all 264 accounts were viable reactivation targets;
• outreach occurred to every account;
• the $67,000 account returned;
• a specific amount of revenue was recovered;
• the same method will produce the same percentage in another company;
• every ERP dataset is ready for the same analysis;
• AI should make customer decisions without human review.

Those outcomes would require additional evidence.

A responsible lapsed-account analysis process

The exact implementation varies by business. A controlled process should cover the following areas.

Define "lapsed"

The company must choose a definition appropriate to its sales cycle. A customer with no order for several months may be normal in one industry and unusual in another.

Document:

• inactivity period;
• order, invoice, return, credit, and cancellation treatment;
• account merges and name changes;
• distributor or channel effects;
• territory changes;
• active contracts or open opportunities;
• exclusions.

Validate the source data

Check account identifiers, dates, currencies, duplicate customers, missing transactions, credits, and historical coding changes. Business owners for sales, finance, and operations should agree on definitions.

Classify with traceable evidence

Each classification should be tied back to the records and rules supporting it. Review samples from every category, not only the most promising accounts.

Add commercial context

A lapsed classification is a signal for review, not a complete customer strategy. Account owners may know about acquisitions, closures, service issues, channel changes, seasonality, or deliberate exits that are not obvious in transaction history.

Protect the information

Use approved access, secure transfer, minimum necessary data, retention controls, and confidentiality safeguards. If personal information is involved, confirm the applicable legal authority and privacy obligations.

Canada's privacy commissioners state that organizations using generative AI remain responsible for legality, necessity, safeguards, transparency, and accountability.^[2]

Put people in control of action

NIST's Generative AI Profile identifies confabulation and human over-reliance among relevant risks.^[3] The business should review classifications and decide what outreach or operational action is appropriate.

Refresh the view

Account status changes. A useful process defines the refresh cadence, data checks, exception handling, and responsibility for reviewing new classifications.

Could this apply to another manufacturer?

It may apply when the business has sufficient transaction history, consistent account identification, usable data, a meaningful definition of lapsed activity, and a commercial owner prepared to review the findings.

A discovery step should determine:

• where the sales history resides;
• how accounts are identified;
• what "lapsed" means for the buying cycle;
• which data restrictions apply;
• what quality problems exist;
• who will validate classifications;
• how the team would act on approved findings;
• how results would be measured.

Frequently asked questions

Free 15-minute AI strategy call

See the source evidence.

Wallai publishes the project figures alongside other client-de-identified manufacturing work on its proof page.^[1]

Book the free 15-minute AI Strategy Call

Sources

1. Wallai, “See what AI has actually built for a business like yours,” Manufacturing & Industrial section, accessed July 17, 2026. wallai.ca/proof
2. Office of the Privacy Commissioner of Canada, “Principles for responsible, trustworthy and privacy-protective generative AI technologies,” modified May 6, 2025. priv.gc.ca
3. NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1, July 2024. doi.org/10.6028/NIST.AI.600-1