.avif)
RewardPulse Automates Proof-of-Purchase Checks
RewardPulse designs loyalty and incentive programs for other companies. Reliably validating each proof of purchase at scale turned out to be far more complex than expected.
.avif)
RewardPulse is a French company that designs and runs engagement programs on behalf of other businesses: loyalty programs aimed at end customers, sales incentive campaigns for distribution networks, referral programs, and internal employee recognition platforms. A Smartbox subsidiary, RewardPulse provides a catalogue of rewards and experiences that participants redeem with points, along with hands-on support to design and sustain these programs over time. Its programs run for brands present in several European countries, which means handling participants, retailers, and purchasing habits that differ significantly from one market to another.
A Simple Action for the Customer, a Heavy Check for RewardPulse
Behind most of the programs RewardPulse designs lies the same mechanism: a customer, a salesperson, or a reseller makes a purchase, then submits a proof, a receipt or an invoice, to unlock their points or reward. This proof of purchase is the piece that triggers everything else in the program: without validation, there are no points, no reward, and an unhappy participant. As long as campaigns stayed small, checking each proof of purchase by hand, retailer by retailer, line by line, remained manageable for RewardPulse's teams. But as soon as a program scales up, such as when a campaign was launched for the car maintenance network Speedy, that manual check becomes the bottleneck of the whole program: it is what sets the delay between the customer's purchase and the reward reaching them.
Why a Proof of Purchase Is Hard to Read Automatically
A receipt is nothing like a standardized document. Every retailer prints it with its own layout, its own abbreviations, and its own field order: the product code sometimes appears as a thirteen-digit EAN barcode, sometimes as a retailer-specific label, sometimes as both at once. The amount that matters for validating a purchase can be the total including tax, the amount excluding tax, or the price of a single item buried among dozens of lines in a full basket. Participants, for their part, don't photograph their receipt under the conditions of a desktop scanner: they snap it on a corner of a table, at an angle, with a shadow or a fold that distorts the text. Thermal receipt paper also fades over time, which leaves some proofs barely legible by the time they're submitted, sometimes weeks after the purchase.
For a program running in several countries, different date formats, different currencies, and local retailers the extraction model has to learn to recognize, on top of already-known national chains, all add to the difficulty. Finally, a loyalty program has to deal with a structural risk: the same receipt submitted twice, whether on purpose or not, to claim the same reward a second time. A check that only reads the fields without comparing each new proof against those already processed leaves that gap wide open.
The Solution Built With Koncile
RewardPulse built its proof-of-purchase check around Koncile's data extraction. Proofs are collected through several channels, scan, email, or direct upload in the program's application, then sent to Koncile over the API for analysis. The extraction model dedicated to receipts, already trained on this type of document, retrieves the useful fields: product code or EAN, description, quantities purchased, amounts excluding and including tax, retailer, and purchase date. This model stays adjustable directly by RewardPulse's teams, in plain language rather than technical rules, letting them add a field or refine an instruction as soon as a new campaign requires it.
A validation field then determines whether the proof of purchase is compliant: valid proofs are accepted, those missing an element trigger a request for more information, and those that don't match the program's rules are rejected transparently, with the reason for the rejection. This approach relies on Koncile's data extraction and OCR API, built to turn a document image into structured fields an external application can use directly.
Who Does What Between RewardPulse and Koncile
On RewardPulse's side, the technical team, led by CTO Bastien Benloulou, handled the integration: generating an API key, connecting the proof-of-purchase flow to the extraction model, then securing the webhook that sends each document's status back to the program's platform. That status, being processed, processed, or flagged as a duplicate, flows back in real time, with no one needing to check it manually in a second tool.
On Koncile's side, the support covered configuring the extraction model for this type of document, documenting the API and the webhook, and following the ramp-up: the volume of proofs of purchase to process grew progressively as new campaigns, such as the one launched with Speedy, were added to the scope, without any volume limit ever needing to be renegotiated along the way.
What Automation Changed for RewardPulse
The first campaign to run entirely on this automated pipeline was the one launched with Speedy in autumn 2025: proofs of purchase submitted by the network's customers were extracted, validated, and sent to the RewardPulse platform without systematic manual review. For RewardPulse's teams, the change shows up less in hours saved than in the nature of the work that remains: instead of rereading every receipt to check a retailer or an amount, they now mostly step in on the edge cases flagged by the automated check, meaning ambiguous or incomplete proofs. This foundation then became the basis for other client campaigns, with proof-of-purchase volumes that can vary sharply from one operation to the next without disrupting the processing pipeline.
What's Next
RewardPulse is now evaluating extending this pipeline to programs running in several European countries, which means broadening the extraction model to new retailers and new receipt formats. The same mechanism of collection, extraction, and validation remains applicable in any market, provided the model has been trained on local documents, on the same principle applied at Toyota Assurances, where the underwriting file also arrives captured and checked before being picked up by a case handler.
Frequently Asked Questions






.png)


.avif)

.avif)


