ICICI credits that reconcile in Odoo
The bank already moves the money
ICICI already issues credits. Corporate API Banking One already accepts a composite payment to a UPI VPA. Odoo does not replace the bank.
The work is to make a redemption in Odoo into a credit the vendor can see, and to make the Odoo ledger tell the truth when the bank is slow, silent, or repeats itself.
Payouts are what we have running. Reconciliation is not a second product. The same engagement already compares token state to bank status on a schedule. Statement-level ICICI reconciliation (feeds, unmatched entries, a delta the finance team can act on) is the same shape, built to order, when that is the actual requirement.
You hold the ICICI corporate account and the API credentials. We configure Odoo against them and hand them back.
- Bank
- ICICI, India
- Odoo side
- Token ledger, partner UPI, payout state, scheduled reconciliation
- Direction
- Odoo → ICICI on payout. Bank status back onto the same token. Reconciliation both ways.
- Delivered for
- Cemseal. Construction chemicals, India.
- Availability
- Built to order. Not a module on the Apps Store.
The callback is not the proof
The first successful credit is the easy hour. Production is the rest of the week.
The voucher trusts the callback. A redemption can succeed at the bank and never report back. If token state depends on hearing about it, you now have value sitting in two places: spent in Odoo, or paid at the bank, and nobody can say which.
A replay pays twice. The same redemption hits the API again. Without an idempotency record, the vendor is credited twice and finance finds it in the payout file, not in Odoo.
The UPI is on the wrong partner. The payee VPA lives on the vendor. A stale ID, a shared mobile, a paste into the wrong record: the credit leaves, the intended vendor calls, and the token is already marked spent.
One call per token does not hold. The first version called the bank once per redemption. Volume turned that into timeouts, partial batches, and a queue nobody owned. The bank sees a total. Odoo has to see the tokens inside it.
A 404 is not a business state. An HTTP failure, an encrypted payload that will not decrypt, a profile the bank has not enabled: if that lands as a log line, the vendor is still waiting and the token is still live.
The books close while payouts are open. Tokens marked redeemed, credits not yet confirmed, a to-pay list that is a spreadsheet. Month-end is when that becomes an argument.
Each of those has an answer below.
Token state, then the books
The token holds its own state. Deactivated, activated, submitted, redeemed. Bank success does not get to be the only record. The token is spent when the credit is confirmed, not when the request left.
A redeem log before a second call. Tokens already in a successful (or in-flight) payout cannot be sent again. Replay is a rejected request, not a second credit.
Batch by VPA, not by token. Credits for one vendor in one window go as one composite payment. The bank sees a total. Odoo still knows which tokens made it up. The first per-token loop is retired.
UPI on the partner, checked before the call. The payee VPA is a field we map and refuse to guess. A missing or malformed ID stops the payout. It does not pick a neighbour.
Failures are a queue. Bank response is stored against the payout, not only in a log. Exception lines are a report finance can open. A decrypt failure or a non-success code is a state someone can act on.
Reconciliation on a schedule. A to-pay pass and an exception pass compare what Odoo thinks it paid with what the bank accepted. The delta is raised. It is not absorbed into “we will check it next month.”
That last part is the offering that is not only a loyalty loop. If the requirement is ICICI statement or ledger reconciliation without tokens, the same rules apply: field ownership written down, idempotent writes, a scheduled delta, credentials you hold.
Paid out, and still agreed
Cemseal runs this on Odoo Community: QR-coded tokens on manufactured goods, a vendor app in eight Indian languages, and ICICI credits when a token is redeemed. 561 vendors are on the app. 1,900+ redemptions have been paid to bank accounts. The token is spent when the credit is confirmed. The daily pass is what finance signs off on.
That is the Integration Engineering proof already on the hub, and the mobile surface on Product Engineering. This section links the case study. The payout is the visible half. Reconciliation is why it was allowed to run.
- Delivered
- Token issue, UPI redemption, voucher state, redeem log, to-pay and exception reconciliation
- Vendors on that app
- 561
- Redemptions paid
- 1,900+
- Client
- Cemseal. Named.
- Also on that install
- GST e-invoicing, Community, four companies
Credentials you hold
An ICICI corporate account with API Banking One (or the equivalent product they assign you), sandbox access, and certificates that stay on your side. We do not hold your keys after handover.
A written rule for the day the bank says yes and Odoo does not hear it, and for the day Odoo marks spent and the credit never lands. That rule is decided before the first live payout.
If this is a loyalty or rewards loop: UPI on every payee you will credit, a token state machine, and someone who will redeem in sandbox the way they do on a Saturday.
If this is statement or ledger reconciliation without payouts: which ICICI file or API is the source, which Odoo object it has to match, and who owns a field when the two disagree.
We will not start against production only. The messy cases (timeout after debit, duplicate seq-no, VPA that the bank rejects) have to happen in sandbox first.
We do not resell ICICI access, and we will not build against a screen-scrape of net banking.
Banking & Finance · Cemseal case study · Integration engineering
Which ICICI number has to agree?
Send whether this is a payout, a statement feed, or both, and what a mismatch costs when it happens. We can usually tell you in one reply whether that is a mapped integration or a process the bank portal already covers.