Just finished a 3-week side project to connect Spendesk to our old, on-prem ERP (not naming it, but it rhymes with "Great Plains"). The official integrations list looked sparse, so I rolled my own using their API.
Big takeaways:
* The Spendesk API docs are decent, but their webhook reliability for sync'ing approval workflows was spotty. Had to build a separate polling layer.
* Mapping custom expense categories to our ancient GL codes was manual. Every. Single. One.
* The real win is auto-reconciliation of card spends. But getting the ERP to accept the journal entries via API felt like archaeology.
Anyone else tried this? Specifically:
- How did you handle receipt attachment flow?
- Any gotchas with multi-currency reimbursements?
Honestly, considering a middleware platform like Zapier next time, even with the cost. This was a lot.
Trial number 47 this year.
Three weeks? That's optimistic for stitching together two systems with their own particular brand of nonsense.
> considering a middleware platform like Zapier next time
You're just trading one problem for another. Now your critical financial data depends on some third-party black box you can't debug when it inevitably drops a transaction at 2 AM. Their connectors are just as flaky, and you'll pay through the nose for the privilege.
For receipts, we just dumped the Spendesk attachment URLs into a custom field on the ERP side. Let the accountants click the link. Trying to proxy the file itself through your middleware is a waste of time and storage.
Multi-currency was a nightmare because the ERP's exchange rate table didn't match Spendesk's timing. We ended up pushing the settled amount only, not the transaction amount. Let the ERP do the conversion based on its own dated rates, wrong as they might be.
Building the polling layer was the correct move, by the way. Webhooks are a lie.
If it ain't broke, don't 'upgrade' it.
> their webhook reliability for sync'ing approval workflows was spotty
Standard. We treat all SaaS webhooks as "best effort." Our pattern is a short webhook listener that just drops the event ID into a queue, then a separate worker does the actual fetch via the API. Never trust the payload.
On the mapping, did you script the initial GL code mapping? Even a one-off Python script to generate the config from a CSV saves the manual pain and is repeatable for the next "ancient" system.
Zapier for this is a bad trade. You've already done the hard part - the API integration. Now you own the logic and can fix it when it breaks at 2 AM.
Three weeks is actually impressive given the archaeology metaphor. I've done a similar project mapping to an old AS/400 system, and the GL code mapping was the most durable pain point. My advice: don't map categories. Map Spendesk's merchant IDs, where possible, to GL codes. It's more stable long-term, as vendors don't change often but expense categories get added monthly.
On your multi-currency question, the gotcha is always timing. If the ERP only allows daily rates but Spendesk uses the transaction date rate, you'll have rounding mismatches that the ERP will reject. We had to implement a tolerance buffer and push the settled amount in the ERP's base currency, letting Spendesk handle the foreign currency display. It sidesteps the rate table conflict entirely.
A middleware platform abstracts the wrong layer. You've already conquered the API logic, which is the core value. Zapier would just add another point of failure for the data transport, not solve the mapping or currency problems.
Data over opinions