At a Programmable Banking community meet-up, Rijnhardt Kotze shared his demo of Spend(d) Co, which takes the pain out of managing expense claims. It is a nifty digital solution to tracking and automatically matching transactions on corporate cards.
Transcript of the demo
Rijnhardt Kotze 0:00
So, I am doing a recorded demo. I'm not doing a live demo because the demo gods need to be with me. So I prepped four videos that I'm going to take you through. But first is a little slide deck, just taking you through the approach that we had and why we built this. And then I'm going to show you some videos, and then have some questions and answers. So, without further ado, let's get some screen sharing going. I'm running on one screen, so I won't be able to see Chat; I'll be able to see Chat after the demo. Cool. Share screen. Okay, can everyone see my screen? Yes.
Cool. So it's Spend(d) Co with a double ‘d’, pending a potential rename. So that's why the second ‘d’ is in brackets, because it will probably be renamed before it launches properly. It is aimed at corporate card-spend management. So, we all know that admin is hard. We hate it; so let's bloody automate it. That is the sort of approach that we took with this. The Why, the How, and the Who. The first one is, Why did we build this? Companies need the ability to capture, categorise, and export transactions on corporate cards. Paper-based expense claims are a pain to manage in companies. I know this firsthand. So we are trying to move away from that and trying to create a digital solution towards company card spend.
How It Works
How did we build this? We built this with Ruby on Rails. And we’ve ‘dog-fooded’ this since December 9. We've had about R270 000 worth of company card spend, and card transactions processed and automatically matched through the transactions API. So we’ve had this go through this very MVP, very, very crude system. You'll see the designs; it's not very pretty, but we're gonna get there.
The Who. Who is this sort of aimed at? This is best geared towards your financial humans. That would be your CFOs or accountants or anyone who has access to an Investec card.
This supports both the ICIB and the private banking APIs. So this is not just towards the private-banking side of the business. It is also towards the corporate ICIB API.
There is a sort of [inaudible] there, but we'll get to that. So what features do we currently have within the Spend Co app? We have immediate notifications on card purchases to the cardholder. In December, there was a corporate gift bought from the Lego store. And we actually got the notification from Spend Co, before the actual invoice was sent to the email address from the Lego store. We have immediate notification on every single card transaction. We have a single sign-on. The idea is we piggyback off the authentication from the corporate or from the company. We just make use of their authentication, and treat them as a trusted party or the trusted authentication provider. You can expense with or without supporting documentation.
There are some transactions which by virtue of the transaction do not generate a document to prove that you made the transaction. And we have automatic transaction mapping to the same currency. So what happens is [that] once the payment clears through the API, we will automatically find the authorisation; we'll automatically match them up, and we can export it based off that automatic mapping. We have expense categories. The idea is you can categorise, however you'd like to categorise, your spending. And you have the ability to provide an internal code as well as an external code to your categories. And then you can export it to your accounting system. The idea is that after you've matched them ie reconciled them to the API and to your authorisation, once that mapping or that match has happened, you can export or batch it, with supporting documentation, to your accounting system. That's currently the feature set that we have developed. Now it's some demo time. Any questions on that before we get to the demo?
Malan Joubert 5:06
That makes a lot of sense. And thank you for that..
Carina De Almeida 5:13
Just a quick question. So when you get that notification from the Lego purchase, which just seems dodge, let's be honest, some creative gifting there? Is there a feature that then directly tracks or traces all purchases on that card, does it just remain general? You can't use it forensically, perhaps at this stage?
Rijnhardt Kotze 5:41
You'll see in the demo, that notification has got the merchant information, it's got the details on how you transacted and where you transacted. From a forensic point of view, there is no feature currently to say this was a dodgy transaction. The ability is to say you spent money on the card. From there on, you can take further steps. If this was fraudulent, you can take that by contacting the bank to say this was a fraudulent transaction, it needs to be reversed or it needs to be charged back or whatever the case may be. There is no forensic component to this app just yet.
Carina De Almeida 6:20
Thanks.
Rijnhardt Kotze 6:23
So, Demo, before we get to the challenges that we faced. The first video that we have is the single sign-on authentication. We've been testing this off of a company called Horizon Data. It's one of the beta users for the dogfooding. This, they run off Microsoft Azure Active Directory, so we listed it as an application within that, and you actually log into Spend.Coone of two ways: you log into it through the My Applications on Microsoft.com or you log into it by providing your email address on Spend.Co. So just a quick little demo here. Oh dear, it's very blurry. Let's see if we can push up the quality before we get there.
Cool, so it just shows my applications on Microsoft.com. Spend Co is there.
It'll authenticate you through Active Directory. It redirects you to Spend(d)Co, having logged you in automatically. Then you can have a look at all the authorisations that have gone through your card. I'm going to log out now. And I'm going to sign back in. It authenticates you through Microsoft, and it logs you back in. That's the sort of single sign-on demo. The second demo is expensing with an invoice; so you have a receipt or an invoice that you can attach to the transaction. [...] So you'll see that there is a $325 charge on a subscription from Fivetran. We'll open it up so that there's not a pause here quickly. So touching on that point, Carina, so currently while this is in MVP phase, we show a crazy amount of detail in the notification coming in. Once we have the new designs coming in, which we'll talk about a bit later, we are going to remove this metadata and actually show it in the user interface. So the idea is the email is going to be straightforward, but we can see the country of the transaction; we can see the categorisation from the actual API or from the notification; and we can see the date and time and the reference that was created for this transaction. We see that it matches the invoice and you can click on 'Create an expense', it will automatically log you in. We can then go and see [that] the amount is pulled through; the merchant is pulled through automatically; and we can choose a categorisation. We provide a description as to why you spent the money.
You provide a supporting invoice. You can upload more than one document as well. And it uploads and the expense gets created. So that is literally the entire process of creating an expense. It's a pretty straightforward approach. Then the third demo here is what happens if you don't have a supporting invoice? So how does that transaction flow work?
We can go to the list of authorisations; we see that there are 79. My admin is terrible; we know this. So we go and see the Gautrain. When you transact with the Gautrain, you can actually use your bank card, and just tap your bank card instead of the Gautrain card and the idea is you can then go from there to see ‘who?’. Gautrain. ‘Passenger railways’. Going to take me a while to realise it's at the top.
Community Questions
Carina De Almeida 10:57
Sorry, this will be done by the user directly, the one who swiped the card, to categorise? Correct?
Rijnhardt Kotze 11:03
That is correct. Yes, based on. So once that email is received, you see that, hey, so you are the registered card holder or the link card holder to this card; money was just spent on your card; you're going to get an email; you're going to click on ‘Claim’ or ‘Provide context to this transaction’. And then you're going to say, you're going to choose a category. And you're going to provide a brief description of why you spent that money. You're going to say ‘Parking at Gautrain’. It's a crazy amount; it's crazy expensive for parking. But, anyway, we can bypass the document requirement and create the expense. The last one that I want to show is the automatic transaction mapping between the API, the transactions API and the authorisation that comes through.
So we see that I purposely go back to find an old transaction. So I take the transaction from the 17th of March, the transaction has come through the API already. I see "Provide context" here.
Just want to pause here. So the transaction has already been linked; this is just the ID for the transaction in the back-end, but the transaction has already been linked to this authorisation. So there's no manual need to reconcile it now, because we matched the authorisation and your transaction automatically. And that is it from a quick sort of recorded demo perspective. Before we move back to the slides. Are there any questions on any of these videos that I need to sort of replay through. I know I have five minutes left?
Cool. So, going back to the slides…
Unknown 13:14
Sorry, Rijnhardt. Question. Yes. When you were talking about automatic reconciliation, I thought you meant automatic categorisation. So, would it be possible to set up a pattern, if it matches Gautrain, then automatically categorise it to transport or railways or whatever?
Rijnhardt Kotze 13:32
So that is something that we can do. It's just not something that we have implemented just yet.
Carina De Almeida 13:43
I think this is a really great product with very many possibilities in terms of additional features that can be added. It's really wonderful.
Rijnhardt Kotze 13:51
Yeah, we've had a few brainstorming sessions; there's a lot of possibility here. The challenges that we faced? So there was one big, massive challenge that we – well, not massive – there was one noticeable challenge that Tim faced. It was that the ICIB returns two transactions from the API for every transaction that you swiped. So there's one for the pending transaction, and there's one for when it clears. You just need to be able to say, otherwise, you're going to be importing that transaction more than once. And the private-banking API only returns the transaction once it's cleared. So that's the two or three days afterwards. So that was the sort of main challenge that we faced. Other than that, it's just sort of linking these things together.
So what are the next steps? We've got some designs and we got some pretty pictures on how to make this look better; doesn't make this look like an MVP. Then we are going to onboard our first corporate user. We are in the process of onboarding them to test with. We are rolling this out to more companies. If you are keen to get involved testing this out with us, let's chat. And we want to implement three-legged OAuth once it's properly released. The new designs; so a sneak peek at the new designs coming in. The idea is that this is what that email will look like: ‘we've noticed that you used your card, follow the link to complete a report as to the transaction’. You can then provide context as to how you spent it; [this is] sort of showing that you are 30 minutes faster than your company average in providing context to transactions. If you really want to sort of gloat a bit. Then, the last one is just the categorisation for your total spending over however many days you want to look back. So, that's just a quick sneak peek at the new designs. How can you get in touch? First one is, reach out if you're interested in automating your business card spend. We'd love to talk further. And join us; we are hiring. We are quite aggressively hiring. We're looking for four intermediates and three senior developers. So yeah, apply through BambooHR or drop a Slack if you're keen. So that's that. Any other questions before I sort of hand over back to Nick?
Malan Joubert 16:32
Really cool progress and nice designs.
Rijnhardt Kotze 16:34
Design kudos to Matt Rich, who's on the call here. So kudos to him for the fancy-looking designs.
Nick Benson 16:46
Awesome, very cool.
Guys, if there's anything else. We’ll share the slides, decks, everything post one of the sessions. Feel free to reach out on the chats on Slack, wherever. Cool. Thank you very much. That was very cool, man. Well done. I digged it.
Get involved in the Programmable Banking Community.
If you have questions or just want to say hi to the Programmable Banking Community core team, you can pop us a mail and we will get back to you.
If you want to see more from what the community has been up to, you can:
- Join the Programmable Banking community
- Browse the community’s open-source projects
- Read the dev docs
- See more demos
- Read other programmable banking related blog posts
