Correcting transactions categories

As accurate as Bud's enrichment is, there will always be times when a customer may disagree with the category that has been applied to a transaction. This is why we have created customer corrections, a way for you and your customers to provide feedback and correct a transaction or group of transactions.

We currently support corrections for merchants and categories. In this guide, we walk you through how you can interact with our category corrections APIs and give you inspiration for how you can build the best experiences for your customers when correcting a transaction.

Category Corrections

Customers can correct the category of a transaction using the Correct Transaction Categories V2 endpoint. This allows you to correct either the L1, L2 or both for a single transaction or a group of transactions. Please note, there is no validation between this endpoint and our L1 and L2 taxonomy mappings, therefore if you're correcting an L2 category we strongly recommend that you also update the L1 category.

As part of the object in the request to this endpoint, we also allow customers to correct similar transactions. By setting the include_similar field to true we will also correct any similar and future similar transactions with the updated category. As a client, you can find a list of your customers similar transactions by using the Similar Transactions endpoint. When calling the endpoint if you provide a transaction_id we will then return a list of all the similar transactions for the given transaction_id.

📘

Please note, any corrections made to transactions will only immediately impact the customer making the correction. Customer corrections are stored and may be used in subsequent model retrains.

Webhook

Clients can subscribe to the corrections.category.corrected webhook, this will notify you each time a transaction has had the category corrected, situations where this could occur include; when future transactions are ingested that are similar to existing transactions when the include_similar flag has been set to true, when a transaction that has been corrected gets updated such as moving from pending to booked or when new corrections are submitted. The webhook content will include both the transaction_id that has been corrected as well as the category that it has been corrected from and to. You can see an example of this webhook below.

{
  "customer_id": "test-customer-id",
  "completed_at": "2024-07-23T08:36:31.103079Z",
  "corrections": [
    {
      "transaction_id": "test-transaction-id-1",
      "from": "utilities",
      "to": "shopping",
      "attribute": "category_l1"
    }
  ]
}

Customer Experience Best Practice

When displaying enriched transactions back to customers we always advise that you give customers the ability to correct transactions. By enabling the customer to correct transactions themselves it increases customer satisfaction and reduces the chance of the customer getting in contact with your support team. Our recommended entry point for this customer journey is when the customer is viewing an individual transaction.

We suggest showing the customer a list of L1 categories, assuming that you're also using L2 categories we would recommend that a customer has to drill down into these by first selecting an L1, this avoids showing customers a list of 100+ categories.

Once the customer has chosen the new category it's important to also allow the customer to correct similar transactions.

You can create a list of similar transactions by calling the Similar Transactions endpoint. If the customer chooses to update all similar transactions then you can use the include_similar flag when calling the Correct Transaction Categories V2 endpoint, otherwise, we recommend sending a single API call with an array of objects specifying the transaction_id's that the customer has selected.