As consumer product companies adopt more sales channels, payment gateways, and as sales grow, so do the hours spent every month on manual payouts reconciliation processes.

Celigo’s Payout-to-Reconciliation Business Process App automates payouts reconciliation for Stripe and PayPal in NetSuite. Join us in this on-demand webinar to learn how this app automates reconciliation processes and identifies payment discrepancies and unsettled amounts, allowing you to streamline your accounting processes.

Topics discussed include:

  • Ecommerce payouts reconciliation process overview
  • Benefits of automating payouts reconciliation
  • Demo of Stripe – NetSuite Payout-to-Reconciliation Business Process App

 

Watch now!

Full Webinar Transcript
Hello, everyone. Thanks for joining us for this webinar today. My name is April and I work in product marketing at Silico. I’m here today with my colleague Pravin, who is our product manager for payouts reconciliation apps. So as e-commerce businesses adopt more payment gateways across their different sales channels, how should we handle payout reconciliation has been a major challenge for accountants and accounting departments. And today we’ll be addressing this challenge with an e-commerce accounting 101, providing one simple solution to automate payouts reconciliation in NetSuite. So a couple of months ago, we held a webinar for Paypal payouts reconciliation in NetSuite, and this time we are extending this topic to cover Stripe payouts reconciliation for e-commerce companies. So if you have any questions during this presentations, please answer them through the questions pane, and we will have a Q&A at the end of this session. So first, some background on Silico. We are an iPaaS integration platform as a services company with global headquarters in the US and presence all throughout the world. So through our platform, we help today more than 4,000 customers automate over 12,000 business processes, and many of them are doing e-commerce. And we are actually syncing 6 billion records every month. So just some interesting facts here. And so if you are not familiar with our platform, so on our platform, any application can be connected with any other application and business processes can be automated. And users can build integrations from scratch through our intuitive UI or they can leverage one of our pre-built integrations, which are built on top of the platform to quickly get started with their automations. And one more thing I would like to highlight here is that what’s great about our platform is that it is built to be easily used by business users. So with features such as self-service configurations, integration monitoring, and error management, so business users can easily manage their integrations. And if you would like to learn more about the platform so you can feel free to send us a message or submit a question. So now let’s get back to today’s topic. So if you’re here today, most likely you’re familiar with the challenges of e-commerce payouts reconciliation. And so before I hand it over to Pravin, I would like to do a quick recap here. When we talk to our customers, we see a lot of them are adopting multiple payment gateways across their e-commerce sales channels. And PayPal, Stripe, Amazon Pay, Braintree, these are among the most popular payment gateways they use today. And also many of the businesses, they have multiple accounts to support different business entities or geographies or currencies. And what happens then is that accounting teams, they have to ensure correct payments were received from these payment gateways for every single sales order, and correct transaction fees were charged by the payment gateway. So they have to download payout reports from the payment gateway for each account into NetSuite and match these against sales orders and refunds, and identify any incorrect missing payments. And this is a painful, repetitive process. And it can also become very costly because of all the accounting hours spent on this work every month. So as an example, on the low end, two days of manual reconciliation every month can cost a company over $7,500 a year. Now, you can do the math, and if you know how many days you or your team are spending on this and see what your current cost looks like. And so manual reconciliation is not scalable, so you would need to add in more accounting hours as your business grows and your sales volumes increase. And on top of that, manual processes are slow, and easily, this can cause delays and month end closing. And there’s also a risk of lost revenue. So it’s possible that missing or incorrect payments issued by the payment gateway can go unidentified. So a good thing is that our new payout reconciliation business process app, which is built on top of our integration platform, can help you get rid of any of these inefficiencies by streamlining these accounting processes. And what’s cool is that you can connect multiple payment gateways to NetSuite through one app and automate the whole process end to end. And so now, I will hand it off to Praveen, and he will talk and show us how to automate Stripe and PayPal payout reconciliation in NetSuite. And a quick reminder. So if you have any questions, you can enter them through the questions pane, and he’ll answer your questions at the end of the session. So now, Praveen, it’s all yours. Thanks, Ebru. Hello, everyone. Welcome to this webinar. I’m Praveen. Yeah, and I’m one of the Product Managers who maintain the payout reconciliation business process apps. All right. So like Ebru mentioned, Celigo comes in with a very rich iPaaS solutions, the platform, which can streamline the processes that you are looking for to integrate multiple systems. Precisely talking about the payout reconciliation business process apps, we have started the payout reconciliation business process app by integrating PayPal payment gateway with NetSuite, which is in the outfit. And then we have started to implement a few more payment gateways also that we have talked about and we have seen demand from the customers. And Stripe is the one that we have introduced next. We also have a couple of other payment gateways that are in the pipeline right now, starting with Amazon Pay, which is going to be the next payment gateway. And then the Braintree integration that’s going to be there, as well. All of them will be linked to the NetSuite ERP system. In terms of the process that we follow right now on how the specific integration app works, as you can see here on the screen, what we do is we look for the payout or the settlement transactions, either as a bunch based on the time period that is specified in the request or a report that is generated by these payment gateways, usually, like for Stripe or Amazon Pay where you have the payout reports generated either on a daily basis or on a cost basis from your side. We consider that specific report or the transaction details from the payment gateway. Apply the logic within the Celigo platform, within the app that we have built, where the identification of the existing records that are already available in the ERP and all happens. And then we create a deposit record, a make deposit record in NetSuite, which is associated with your bank account to which the funds are received from your payment gateway, and then close all of those transactions that are linked to it. So there are different types of transactions, other type of transactions that would be supported in the business process app, which are coming a little later. When I show you a product on how it works, etc. But on a high level, what we do with this data that is coming in from the payment gateways is we create a deposit, make deposit record in NetSuite on the bank account that you would wish the deposit record to be created for. And then we also now move these transactions that are the undeposited funds to that specific bank account. And another important aspect I have to talk about in this specific process, is the variance transactions that are highlighted here in this screen. So typically, there are a lot of cases where you might see variances. If your bank or if your payment gateways sending any information in a different process. So what we have as one of the better features, I would say here, is to actually have all of these variances reported in your NetSuite, within your NetSuite account, which will eventually help you to understand the reasons behind the variances that are caused and also to have those variances fixed within the product itself, within NetSuite itself, so you don’t have to work backwards. And again, looking at the data that is coming in from the payment gateways, to do all of this manual stuff again. And a few of the key features that we have as part of this business process app is, like Ebru was also mentioning, we have the ability with our iPaaS platform to consider and also transact with a huge volume of transactions that you might have. So we understand that the companies, your companies are growing. And the number of transactions that you will be receiving, the number of orders that you will be receiving on a daily basis from the customers, would be increasing as well. We are well equipped to make sure that we are able to handle that transaction volume as well, so that there’s no delays or gaps in between what is expected from you and what is delivered by Celigo. So that’s definitely something that we have in place already, which we have covered. And then another key feature that I want to highlight is the option that we have to delay the frequency. So this is specifically for someone who has a few delays in terms of getting in the transaction-related information for the ERPs, where– you might have a case where an order is placed in your web store on a specific day, considering today. And then your web store for some reason, considering all the fulfillment activities that will happen and all, would send you the final transaction with the customer deposit two days later. We have the capability in this reconciliation app to have that process delayed by two days, so that your reconciliation will hold until you receive the transactions in NetSuite. So there won’t be any case where the app tries to identify and search for transactions that aren’t available in NetSuite yet. And the next feature, like I was mentioning is also the flexibility to track not just the transaction, the different information, not just the charges, or payments, or refund, but also the ability to track the transaction fees that your payment gateway would be charging. And also a different type of dispute in case there are any that are happening. And along with that, also the ability to track the non-transactional data information as well, like adjustments on network costs, etc. that Stripe or any other payment gateway usually charges. And then within the integration app, within the business process app that we have, we also have the ability to support the multiple payment gateway accounts in case if you’re using for your business. So I’ve seen customers– I’ve seen sellers or merchants who actually use different payment gateway for each web store that they have. So even cases like that, they are equipped to support those use cases where the customers, where the sellers can actually use different payment gateways for web stores and can still use the single business process app. They have everything under the same. And then one of the other features that we primarily target for is to make sure that there’s no specific requirement for someone like a seller to have any technical background. So in order to make sure that there’s no dependency on any technical understanding from you guy’s perspective, we have built everything which would be like a plug-and-play where we would be creating the flows that are pre-built. But just the configuration of a few settings is needed in order to start using the application. So I would say it’s a pretty simple configuration, which I’ll walk you guys through in some time. But yeah, to add for that again on the last point, on the key features, it’s kind of a self-service where there is absolutely no requirement of any maintenance as well. And we do have a good amount of documentation that is available in the articles and the knowledge case as well that would be used to to know and understand the different settings and the configurations that needs to be used to get this integration app configured and up and running. So yeah, a simple presentation that I actually wanted to talk about specifically for the Stripe-to-NetSuite reconciliation app. If I’ll have to give a little overview on how the integration app works, basically, as we understand, payment gateway can be linked to any of the applications that you have considering the web stores, the other kind of applications where you will be receiving the amounts from different types of customers or vendors, etc. Now, what this Stripe-to-NetSuite– how the Stripe-to-NetSuite BPO works here, is that it integrates all of that information that is coming from different applications then that is integrated with your Stripe payment gateway. Stripe usually creates a payout record on the daily basis based on whatever frequency that you would want the Stripe to create that payout record and then have these details and data available in the Stripe account which I’ll show in a while. Where Celigo comes into picture. As you can see here in the payout reconciliation process there, considering all the data that is available in Stripe, we would be checking in NetSuite to create a Make deposit record and close all the transactions that either comes into this category of customer deposit or Cash Sale, Cash Refund, or customer refund and then move these transactions from an undeposited fund to actually a bank account within your NetSuite, which is already configured to get this process done. So some things that we have to keep in mind when we have to work on the Stripe – NetSuite business process app. This is something specific to the Stripe terminology, where Stripe uses a little bit of a different terminology, considering the other payment gateways and I just wanted to highlight this difference as well to make sure you guys understand it. Balance transactions in Stripe are precisely the kind of transactions or the kind of– each type of events that are occurring in Stripe and it can either be a charge, it can either be a refund or anything like that. And then the types of the balance transactions are basically the detailed version of the transactions that are available in Stripe. And typically, they would be a payment or a refund or a network fee or a currency conversion fee etcetera and all. And then payout, basically payout is actually a group of balance transactions that are available in Stripe, where it’s some lumpsum amount that is deposited in your bank account from Stripe on the schedule basis. Either it can be a scheduled basis, where you can schedule on available days, or it can also be triggered on a manual basis, whenever you would want to as an on-demand criteria. And then reporting category is another term that Stripe uses. And this is a little detailed version of the balance transaction types, I would say, where someone from the finance and the reporting departments would be able to understand and they would have this granular level of break-down. For example, if you take the adjustments– there are different types of adjustments Stripe supports, which are disputes, which are discrete reversals and failed refunds, etcetera, and all, which can be easily identified using the different reporting category that Stripe supports. Getting into a little detail about the reporting categories, as I was just mentioning, so this is something that we have identified from the Stripe documentations, where we have each type of balance transaction and then the reporting category associated with it. So application fee is something that comes into the platform earning and Stripe fee is something that comes in that fee. Similarly, for each of the balance transaction types, we have different type of reporting category as well that we can see here. So basically, these are all something that are for this fee-related information that Stripe has on handles, and these are the actual transactional level of information that usually Stripe has, etcetera. If the reporting category is charged, the type of balance transaction that comes under that is charge and payment. And then for the refund, it would be refund and payment refund. Similarly for the other ones that we are seeing here for the reporting category, there are different type of balance transaction types that we can look at. All right. Moving on to the product itself, I wanted to quickly show you how the product is configured. As you can see here, the payout reconciliation repair is a payment integration, which handles and holds multiple payment gateways that can be incorporated under the single tile itself. So I right now have the tile that is installed in my integration account, where I have the payout reconciliation apps configured with Amazon Pay, PayPal, and Stripe, which are linked to my NetSuite account. So when I open my tile that is already configured, I will have an option to select the payment gateway that I would want to currently work on. And so now, I’m going to Stripe. So these are the two integration flows that Stripe usually– for any integration app that we have. I’m sorry. So these two flows are actually dependent on each other where from the user perspective, there would only be one flaw that will get triggered, and the other one would automatically get triggered as soon as the first flow is completed. So getting into the details, the first flow, the Stripe payout method, payout customer record is basically used to create a customer record in NetSuite, which is equivalent to payout record in Stripe. And then the next flow, which basically takes all the transactional level information that is eye-level in the payout that is coming from Stripe and searches and identifies all the NetSuite transactions that are already available there in order to have them added under the deposit record. So these are the two flows. And like I mentioned, one flow is dependent on the other. And for this flow as well, we do have options to schedule this flow based on your requirement, either once every week, once every day, and you can also do it twice every day and then every 15 minutes as well. So it’s up to the– it’s up to the merchant or the seller based on the frequency of how often the payout records are selected to get created in Stripe, using which you can schedule this flow accordingly so that all the new data that is available in Stripe would be available the same day on NetSuite. Coming to the configuration part real quick, these are the settings that are available to configure. And these are all one-time setup, where you would be selecting all these account-related information so that whenever a record is created, whenever a bank deposit record is created in NetSuite, all of these settings would come into picture so that right details are selected and right values are added under the main deposit record in NetSuite. So starting with the first setting, NetSuite bank account is typically the account on which the main deposit record is created. So as you can see here, this is my account, which I have added in NetSuite to link to my actual bank account, and that is going to be selected here on the first setting, which eventually will be used to be the main deposit record. And then the second one here is to track the variances that I’m coming in for this specific deposit that I create and the account in which these funds have to be redirected. Typically, the sellers would want the variances to be handled in a different account in NetSuite rather than the bank account, because these require some attention afterward to make sure that these are identified day of report, the kind of variance they are, and then correct them and then eventually, these would move to the bank account. And then the next setting is to track the fees and application fee difference in from Stripe. So as I mentioned, Stripe usually charges– I mean, not just Stripe. Any payment gateway usually charges fees for each seller when they are using the payment gateway. A few of the payment gateways charges these fees based on the transaction, and then NetSuite can get these charges based on the usage. So for Stripe, as we have the fees charged based on the transactions here, they have this specific setting added to select the account which should be used to track all the fees that Stripe charges. So you can track all the fees that is charged by Stripe separately. And you can, end of the day, calculate that and then reconcile it accordingly. And then the next setting is mostly for the nonces related transaction types. Where if you will have an– if you have a necessity to track the non-transactional sales related information separately for each of these type of the non-sale transaction in your NetSuite. You can actually add the type of the important category that is coming in from Stripe and add it to a specific NetSuite account, which you would want to track the most. As I was showing in this specific page. This is where you would ideally have the differentiation between the reporting categories available in Stripe from all the transaction and non-transaction related information. And that can actually be used here. We do also add the Stripe link where they have talked about all these reporting categories which can be used in order to get the reporting category being accurately shared. And then the next thing is the default reporting account. This is basically a replacement of the previous setting where if you do not want all of these non-sales related transactions to be tracked separately, you can simply use the setting and then set the NetSuite account in which you want to track all of these payouts. And then the last thing is something that I discussed previously of where we have the flexibility in the app to delay the reconciliation process based on the requirement for your process. And then the values that would be provided in the setting is basically the number of days for which you would want to delay the conciliation process. So delaying the reconciliation process is not something where we’re actually delaying the process for two days and pulling off it. But ideally, this number of days that we add in the setting is basically the line that we are adding for the flow when it runs. And for example, as I mentioned, if I’m trying to run the flow and selecting the start date for this specific floor as– let’s say, if I want to– if I want to start the flow starting it from 29th. So start date I’ll be selecting as 29th. And then– for the start date I’ll be selecting as 29th. And the time as well as I would want. And then what happens when I click on the wrong button? As I’ve said, the lag for two days, the Flow intelligently calculates the start date of this specific flow run to consider 29 minus 2, which is 27. And the data would actually be calculated from 27th to minus 2 from today which is 29. So though I am running the Flow today and selecting the transaction run date, so the flow run date as 29th, as I have specifically mentioned, that there should be a delay for the reconciliation for two days. The indication app then calculates the number of days it actually reduces the number of days for both start and the end date and then considers the payout records that are available in Stripe for those specific dates, right? So that’s about the settings in the integration app. And once you have configured all of these that are needed here and then save the settings, you’re all set. And the next thing that I would want to show you real quick so this is basically my test account that I’ve created for Stripe And I’m pretty sure all of you guys have access to your Stripe accounts, and this is how it usually looks. Talking about the payout and the balance transactions, it’s a channel. And for you, in order to get to that, you’ll have to go to your payments and then click on the payout reports, which will eventually show you the different type– show you the payouts that were actually created it for that specific days. And then you can also have the option to export the transaction-level information into a CSV. I’m very hopeful that most of you would be already doing that as the reconciliation process. But this would be manual right now, that you’d be using the CSVs that are exported from this account and creating these deposit reports in it too. So that’s about the Stripe on how the reports that are represented. Quickly moving on to how this end data is represented in it to. So as I mentioned, there are two flows. So the first flow creates a customer record in NetSuite which is called a Celigo payout. Just open the list of that Celigo payout that are available here and simply do a search with page single payout. And you should be able to get that out. Celigo payout, and you should be able to get that in the responses. So basically, this is the flow that actually creates that customer report. Now, you can see that actually will Stripe payout customer record. And this is the payout customer report that we’re talking to. So once the flow runs successfully, there is a requirement, the customer report that’s created. And this is how the customer report with Stripe looks like. So we have the higher-level information for this specific payout from Stripe. There’ll be clear the name of the specific customer report using the date, as well as the prefix to cancel Stripe payout to differentiate that with other payment gateway payouts in case if you have any. As you can see, I have Amazon payouts as well here and then Stripe payouts. To differentiate that, we give that name. And then you also have the payout data that is captured from the file that is received from Stripe. And then you want to have the payout ID as well that you can quickly use to reference back in payout to mortgage which payout that this specific custom required references to and then the Source Account basically mortgage payment record the card belongs to and then the total amount of that specific payout as well. And once this payout is created, using this flow, then the other flow will get triggers and it creates deposit report in NetSuite. And as I was mentioning, the deposit required will be attached to this custom record in NetSuite, and that can be found under the deposits here. They just open the deposit report. This is typically the deposit report that we must be creating manually right now. It has all the details that we would need to note create the amount. Match the amount for the custom payout that has company Stripe. And also all the transactions that are identified will be recorded here under the payment section for the customer deposits. In this specific case, as I have shown, the Stripe payout that is coming from the Stripe. And then I’ve created a customer report for that– sorry, deposit report for that. And as you can see, the bank account that I’ve selected here is same as the one that I’ve selected here in the NetSuite Bank Account. As we dig a little deep into this specific deposit record, this deposit record would also hold the payout ID that is coming from Stripe under the Memo. And also along with that, all the transactions that are seeing here are something– these are something that comes in from the payment and later information from the Stripe payout data, and these are identified using the specific identifier, as I can show you on the customer record. So this record, basically, has come from my Shopify, which I have integrated with this NetSuite account. And under the e-tail tab, we have the e-tail transaction, maybe, which typically also transaction ID of this specific payment that is received from Stripe. So this is what is used as the identifier when you are trying to match the transactions that are available in NetSuite. In order to match that against it, deposit the record here. So moving on to the next tab that we have here, which is Other Deposits, this is typically the variance reports which are created here for which we do not– so there are two type of variance records which I’ll go into detail some time. But this is the account that is selected, as we have chosen in our configuration for tracking the variances, which is payment gateway variances. And that’s exactly what we can see here. And under the cashback section, we basically have all the details that are related to the fees or of the non-transactions and their data aspects. And as you can see, payment transactions, this is selected for any fees that is coming in from the Stripe account. And for all the non-sales-transaction-related details, payment gateway, Other Fees is what I have selected, and that’s what is there as well. Yeah, so then moving on to the different variances. So as I was mentioning, there are two type of variances that we can see in the business process app for Stripe and NetSuite. The first type of the transaction that might have as a variance is a missing transaction. So this is a common case where you have a payment received for a specific amount from– do you have payment gateway, which is Stripe in this case? And then the integration app failed to recognize a corresponding transaction available in it too. This happens in most of the cases where the transactional-related information is not available in NetSuite yet, which might say that these records aren’t created in NetSuite already, where the billing or the fulfillment hasn’t happened within the third-party systems that you have. And then the transaction is still delayed to be available in ERP, customer deposits or part of cash in the card to be available in the ERP in order to identify that when the integration happens. And this is exactly the reason why we have the lag that we have seen here in the configuration, where you would be waiting for this number of days in order to make sure that these records are created and made available in NetSuite so that you don’t have to look at a lot of these missing transactions once when the payout runs and creates a mail deposit record. And then the second type of variance is, typically, amount mismatch. And this happens in our cases where we have a transaction that is coming in from the pet store, for example, which has $100 order. And when that payment comes in from Stripe, for some reason, the Stripe says that the amount of that transaction is 85 or 86. Now here, there is a difference in terms of the number– in terms of the amount that you are expecting to be– no, received from your payment gateway compared to what is actually there on the transaction. So these kind of differences, rarely seen from the integration app perspective, we would be marking that as a variance with the type, amount mismatch. And again, there is a feasibility on flexibilities for you guys to go edit that specific variance, try a type of transaction, and fix it so that it can further be added under the deposit record again. So quickly showing you how the variant’s record is represented. This is basically, again, a custom record for the variances. You can have three type, which is a text field, and then this is also another source type. So basically, again, the balance transaction type and the reporting category type that are coming from Stripe. And then this is a type of variance you have like I mentioned, two type of variances one is a missing transaction in this case. And then the other one is a anonymous match. And then for the missing transaction, you will have the ability to actually select an extra transaction in case they aren’t created and available already. And for some reason, we didn’t identify maybe because– the identifier that we were talking about, let’s say, for the EK transaction would be in this case, is not accurate or not popular for some reason. You can select that extra transaction maybe here and then save this report. Along with that, under the ID section, you will also have the payout ID and the source transaction ID for which is coming in from the Stripe Payment Gateway to cross-check as well to understand the amount and the type of that specific transaction that is coming in from Stripe. And as I was mentioning that we do have a good number of articles made available in our knowledge base, which you can go and refer have a look at it. All of these documents are public. You can have a look at them, try to understand, and get more information on how this business process app works. And coming to the scheduling of the flow, as I was mentioning, the flow runs based on whatever you have, the preference. You can use the frequency to visit between once a week to every 15 minutes as well. And based on your selection, the records would be fetched from Stripe based on the availability there in Stripe. And then bring the details back in order to create that records. All right. That’s pretty much it from the demo perspective on how the integration app looks like and the different types of records that are handled in Stripe. And different type of records that are created in NetSuite as a custom report or as a transaction information. So, yeah, that’s how it functions. Okay. Thank you,Praveen. I guess I’ll take over here. Okay. So I see there are already some questions here and we’ll be answering them within a minute. So before moving on to the Q&A, I would like to do a quick recap here. So when you think about the key benefits of automated payouts, reconciliation, so these help businesses speed up month-end closing and improve financial visibility. These boost accounting productivity by allowing accountants to focus only on managing exceptions instead of manually checking every single transaction. And also, an automated payout reconciliation process helps reduce accounting costs by cutting off on all of the work hours put into the reconciliation process. So after this webinar to learn more about the payout to reconciliation business process app and also to learn more about our other solutions or customer stories, you can visit our website at silico.com. And you’ll see on the resources, we have a lot of guides, e-books, and case studies you can download and explore. And now I would like to move to Q&A, so let’s see. So first of all, first question is, will a recording be shared? Yes. We will share the recording of this webinar with all attendees. And then another question is, could you please elaborate, what are non-sales transactions in Stripe? Praveen, could you take this question? Sure. Sure, April. So Stripe usually has the fees that is charged on the transaction level. Apart from that, there are also different kind of charges that Stripe has, for example, network cost something that Stripe usually charges based on the amount of transactions that you have. That is a non-transactional sale, a non-transactional, no sales-related transaction. And then we also have adjustments that another month’s sales-related transaction. And the other one that I can think of is actually a Stripe fee, which is again, not related to a transaction, but an overall Stripe fee, which is a non-sales-related transaction again. Thank you, Praveen. So another question is, will this app work if we do not have individual customer deposits on NetSuite? So currently, this app handles in customer deposit and cash sales in order to identify the transactions that are coming in from the stores or any other applications that you might have all linked with your ERP. And in case if there is no such record or if you are just using a single recording entry instead of going with a multiple individual requests for transactions that are happening outside of your web stores. It would really be difficult for the app to identify each such transaction based on the information coming in from the payment gateway. So having individual transactions. It can either be a customer deposit or a cash sale. Both works in the integration app. Great. Thank you. So another question is, I’m new to Celigo, is there a place I can go to make sure I download the correct integration app? I can answer this one. So you can visit our website and then go to our marketplace there and search for the path to reconciliation business process app, and you can find there more details and instructions. Also, we can share with you resources and links after this webinar. So let’s see. Okay, another question is, how does reconciliation tie the charge to a payment record? Okay. So customer payment records are not supported right now in the integration app. Like I mentioned, we support customer deposit and charge and cash sale. So what happens is whenever a charge is made from the payment we pay, the search for that– the search either for a customer deposit record or a cash sale recording in NetSuite and then link that to the make deposit records. And if there is actually a customer payment created for that in your ownership, that’s not supported at this point. So maybe to elaborate a little bit on that, different type of reporting categories from Stripe versus what we support in NetSuite. For the reporting category thats charged, we support customer deposits and cash sale for that, and if the reporting category is refund, we would support customer refund and cash investment for that. Thank you, Praveen. So let’s see, so another question is, what about the payment in NetSuite as opposed to a cash sale? Yeah. I think I just answered that. It isn’t supported right now. Okay, and let’s see here. Can we post two different bank accounts in deposits based on country of origin or any other specific criteria? Yes, so that is– if I’m not wrong for this specific use case, you would either have a different Stripe account which you would be configuring because based on whatever bank account that you have linked with your Stripe, you would be selecting the option in the dropdown. So for your case, you might need two different Stripe stores that you should be configuring with your metric and each bank account should be selected in each store. Based on your country, you’ll be having different stores that you would be connecting to in your metric bank account. Okay. Great, and I believe this is a follow-up question. What if you only have one stripe account? So if you have only one Stripe account that you have linked to multiple banks. At this point of time, you cannot have multiple accounts selected, but we are looking at a way to actually make this work instead of looking at the setting, handlebar, or something. Again, leveraging the Celigo’s iPaaS platform solution to see if that’s a possibility. But at this point of time, obviously exploring that option, and I think we can get back to that question to get an answer. Okay. Great. Thank you so much, and I’ll take one last question and then I see there are actually more and we can follow up with you after the webinar for any unanswered questions. So the last question is, does Celigo provide any training? And so I can answer this one. First of all, we have Celigo university, which we launched last year, and through Celigo university, all of our customers get access to classes that cover anything they would need to know to build and manage their integrations. And also as Praveen showed during his demonstration, we have a large selection of knowledge-based articles available that really describe in detail all the future settings and configurations users need to be aware of. And yeah, so we are at the end of our time here. And so thank you so much for attending this webinar today. And as I mentioned, you’ll all be receiving a recording of this webinar and we will follow up with you all for any unanswered questions. So we are always interested in hearing about your business problems, your integration challenges, or any questions you have for this particular part of the reconciliation business process. So please feel free to contact us after this webinar so you can email us at [email protected], or you can simply visit our website at celigo.com and submit your questions through the chat window. So thanks again for joining us today and have a great rest of the day. Bye everyone.

About the speakers

Ebru Saglam

Ebru has a diverse background with over a decade of combined experience in marketing, technical sales and customer services roles across startups and enterprises. She also has hands-on experience in the e-commerce landscape, she has spent more than 5 years running her DTC multi-channel e-commerce business.

Praveen Kumar Reddy Basani

Praveen is a Product Manager in Celigo, currently responsible for Prebuilt Integrations. He began his career in Engineering and has over 7 years of experience in building and managing SaaS applications in Banking, eCommerce.

Meet Celigo


Celigo automates your quote-to-cash process with an easy & reusable integration platform-as-a-service (iPaaS), trusted by thousands of eCommerce and SaaS companies worldwide.

Use it now and later to expedite integration work without adding more data silos, specialized technical skillsets or one-off projects.