My ERP does not show purchase frequency

The limitation is analytical, not a reason to stop

The ERP remains the record of orders, invoices and returns. It may not calculate the interval between purchases or identify an account whose pattern changed. Keep it as the transaction source and build the frequency view separately. That separation also makes the calculation easier to review when a commercial team questions a flag.

Export a dataset that can be checked

Export one row per order or invoice line, using a defined period and the same date basis throughout the file. Include the customer identifier, order or invoicing date, product or product line, quantity and value. Keep the document number and status when available so the team can trace a result back to its source.

• Customer identifier: use the ERP code, not only the display name.
• Date: choose order date or invoicing date according to the commercial question.
• Product and line: preserve both when the ERP offers them.
• Quantity and value: retain both, because a repeated date alone does not describe the account.

Normalize first, then calculate outside the ERP

Before calculating, define how cancellations and returns are represented. Exclude fully cancelled documents from the purchase sequence. For returns, use a documented rule: remove a reversed transaction, or retain the original purchase and record the return separately when it still matters to the commercial conversation. Apply the same rule to every customer.

Use a spreadsheet for a controlled first version or a database when the export needs joins, history or repeatable queries. Group the cleaned records by customer and, when useful, by product line. Order the dates, calculate the intervals between valid purchases, identify the most recent purchase and compare it with that customer’s own pattern. The result is a working hypothesis, not an automatic verdict that the customer has left.

Give account owners an action list, not a raw report

Each line in the returned list should name the customer, responsible owner, relevant product line, last valid purchase, observed purchase pattern, current exception and a proposed next action. The owner can then verify a known pause, an open quotation, a delivery issue or a change in the buyer before contacting the account.

Close the loop by recording the owner’s finding and decision in the same working view. This distinguishes a data issue from a commercial issue and improves the next export without turning the spreadsheet into a second ERP.

This is not a CRM replacement project

Changing CRM may be appropriate when the sales process, ownership, contact history or follow-up discipline needs redesign. That is a separate decision. This workflow starts with transaction data already held by the ERP and creates a dependable review routine before any system change is considered.

It is also distinct from the RD Station cluster. Those pages address CRM adoption, configuration and commercial process. Here, the question is narrower: how to turn historical ERP orders into a frequency signal and a responsible person’s next action.