Hello everyone and welcome to today's webinar about bookkeeping integrations. My name is Lucas Andersson. I'm one of the project team leads here at Omnitas. And today we're going to take a look at how we can use both monday.com in collaboration with make.com as an integrations engine to essentially allow for a bookkeeping integration and integrate that not only just integrating the systems, but also how can we use that efficiently within monday.com to make it more useful in our project management workflows. So what we're going to go through today is first off, we're going to have a quick chat about what type of challenges do we usually have when we don't have this type of integration, which in of itself also explains what challenges we aim to solve with these types of integrations. We're going to have a look at a integration flow more from the point of just having something to talk around to explain essentially how the general setup would look like and how that data would be transferred between monday.com and your bookkeeping system. And then finally, of course, we're also going to look at an actual demo where we can see how this can be done. And of course, also we have something in make.com to show you how one of the bookkeeping integrations with one specific service might look like as well to give you even more insight into what part make.com actually plays in that integration. So starting off with challenges, then these are the three primary challenges that we usually encounter when we're talking about a bookkeeping integration. So first and foremost, it's really anything to do with the visibility between our project management organization and our finance team, especially for mid to larger size companies. These are generally very separated departments. And often it's the case where a project manager, for example, working in a project, want to send an invoice to a client or want to essentially say that this project is ready to be invoiced for either the full amount, part amount, whatever it might be, then they have to contact the finance department to actually put that invoice in and send it to the client. And then in the other direction, of course, finance gets their supplier invoices that they need to tie to some project potentially, so that that will actually count against the profitability of that project in the end. And this, of course, often leads to a delay in invoicing primary client invoices. This might be a bit dependent on how the specific company invoices, especially for professional services companies that might invoice either as we're doing the services or as we've completed a set of services, then just having that invoice get sent out a lot quicker is often the time is oftentimes the difference between actually getting paid quicker and increasing that liquidity in the company as well. And then finally, is doing the project economy assessment. What I mean by this is if we have this information readily available, meaning what have we sent to our client, so money in in terms of client facing invoices, and what have we spent on this project, both in terms of, of course, internal resources, for example, if we count our internal resources through time reporting or such, but also the supplier invoices that are tied to our project. So being able to both follow up on that spend versus invoice of a project as that project is being executed on, but also once we close that project, not having to wait months or, or even longer to finally be able to do that assessment for a specific project, if that project was profitable, and of course, be able to take that into consideration for lessons learned from that project. So moving on a bit to the integration flow. This is roughly from a high level how an integration like this might look. So the pieces we essentially have here is 3 primary monday.com boards, which we're going to look at in a second, which is going to be the projects board, the essentially just the board that contains our list of projects, one row equals one project, which is usually in our project management setup is the centerpiece of anything to do with that project, whether it be tasks, capacity and resource management, or in this case, anything to do with invoicing client invoices or supplier invoices. And because those two are also, even though the data in them is fairly similar, the purpose of them are opposite each other, then we usually also have two separate boards for each purpose. So we would have one monday.com board for client invoices and one monday.com board for supplier invoices so that they're separated clearly, since we're also going to interpret them in different ways and potentially have different sets of data that move through. The primary difference between them is of course going to be in this example, we assume that we want to give the project managers a ability to create their own client invoices, since they are usually going to be the ones that are most connected with the client and project and know what needs to be invoiced and when, especially if it's a question of it's going to be invoiced at delivery. So the PM would have access to a board like this, the client invoices board where they can define that invoice, of course, also pull some data from within monday.com where everything else lives in terms of what project it is, if there's any project identifiers that should be included on the invoice. And of course, also, if it is the case that we have our CRM in monday.com, or at the very least some form of client registry that is connected to that project, then we can also save that information in monday.com and build a workflow around it so that the PM essentially can just select the project. By knowing the project, we know the client, by knowing the client, we already know the invoice. So we can then build in some specific functionality around it, should they be able to override anything, for example, if it's a specific client, but that invoice specifically needs to go to either another sub department within that client or potentially simply just changing what the client reference on that invoice should be. But so for that workflow, and as part of the integration, the client invoice would first be defined within monday.com, and then we can essentially copy the same invoice over to our bookkeeping software, since the bookkeeping software is in the end going to be our master data in terms of bookkeeping for compliance purposes. And in the other direction, then, when we receive any supplier invoices, we're going to receive those to our bookkeeping software. So that's going to be the starting point for that. And then we can also generally build an integration that goes in the other direction, where when we receive supplier invoices, we're going to pull that into monday.com to make that information more readily available to the PMs and also connect those potentially to projects. Generally, this is done in a couple of different ways, since when we receive a supplier invoice from any supplier, it's going to look different depending on who that supplier is. And generally, when you want that connected to a project, you're going to ask them to include some form of unique identifier. So oftentimes, it's either going to be a question of, can we, depending on the bookkeeping software, also sync our project list into there so finance can actually do that connection there? Otherwise, once it's in monday.com, we will always be able to do the connection there. Quick mention here as well is that this is oftentimes also a good use case for AI, where we can simply ask the AI to look at a PDF copy of that invoice and ask it to look for a specific format of a project unique identifier. So let's say all of our project references start with PMO and then four numbers, then we can generally ask that AI to just find that on any given invoice. And of course, if it fails, we can notify so that a human will look at it. Just something to be aware of. And then, of course, in the middle of all of this, we have make.com, which for any of you who haven't heard about make.com before, make.com is an automations and integrations engine. What that essentially means is that they have a lot of readily available connectors and plugins so that when you create integrations between different systems, you can do so without actually having to do custom coding. So for example, me who builds a lot of Make, I'm not an actual programmer, but I can still build fairly custom and advanced integrations. Some other small pieces here with worth mentioning as well is that these arrows are the general directionality of how the big pieces move. But oftentimes we also have information traveling in both directions between monday.com and the bookkeeping software for both client invoices and supplier invoices. Examples of those being the client invoice itself would be copied over to the bookkeeping software. As mentioned, but then after that point, we might want a sync back to monday.com for if it's been partially paid, if it's been paid or if it's been past due date, as an example, then oftentimes we build a sync back to that so that the PM has access to that information as well. For supplier invoices, it's often the case again that we pull the supplier invoice in itself into monday.com, but then we might have like an approval workflow as an example within monday.com where the PM would actually approve that supplier invoice to make sure that yes, this is a supplier invoice that I'm actually expecting for this project. And then that information would move into the bookkeeping software. So again, finance, even if they of course can get into monday.com, potentially, the idea here is that the PMs can do all of their work and have access to all the data that they need within monday.com. And finance has access to all the information that they need within the bookkeeping software. That's kind of the idea of this integration. Super. So let's move into the example. So first, fair mention about what we're going to look at as part of the demo. The demo is built into partly the PSO product that we have, which is a ready to use professional services suite. If you're interested in learning more about what this contains since today, we're just going to very briefly go through the basics. But it contains a lot of other good pieces. But if you want to learn more about this product, then there's a separate webinar run by our CEO, Thomas, which you can find on our website at www.video.omnitas.com. I'll also paste the link to this in the chat for those of you following the webinar live. And for any of you who are watching this, for example, on YouTube later, you'll find the link to it in the description as well. But so briefly talking about the general specifics of how this product is set up. We have, as I mentioned previously, a project board that are going to contain our full project list. One item is a project, and this is going to be the centerpiece of our entire project management organization. Worth mentioning in here as well, since that's going to tie into this purpose that I mentioned before, the challenge of having a complete understanding of our project economy, something that's also part of this and is something that's generally well done within monday.com. Is planning for our capacity. So both our resources for planning purposes, and of course, also time reporting. So some things that we do have here as well for these example projects is we can plan both in terms of what's the budgeted planned hours. And then, sorry, what's the budgeted hours for the projects? What are our planned hours for this project? And then we can use that information to convert that into dollars and cents so that we have a internal cost, whether that be by project by person or by role, then we can get an internal cost based on that. But we'll get to that piece in a second. So these boards here down at the bottom, the finance and billing boards are going to be the ones that we looked at previously in our integration flow. So our client invoices and our supplier invoices. So starting out with the client invoices, the intention of this is essentially to build it to as closely resemble how it would look within an actual bookkeeping system. So in this case, one item or a main item right here is going to be the entire invoice. And then we're going to be able to also define the invoice items as sub items in this board. So in this case, we have a project here that we're looking to invoice for. And we're going to invoice for two hours of scoping and 15 hours for the first iteration. We can define which unit this is going to be. And which is the what is the price per unit if there's a discount. And then we can get that rolled back up into the main item. So right here we see the totals as they're defined on the sub item. So again, pretty similar to what you would see in an actual bookkeeping software. But since this is within monday.com, we also have access to all of the other data within monday.com. So right here as an example, this is what's called a connect column. So this is a connection to another board. In this case, our project list our board. And then we have a project list. So when I open this, or if I create a new invoice here, and I want to say it's for this project, then this is going to pull straight from our projects list for which project this invoice is tied to. And this does two things. Number one is we can, as mentioned, pull some information from it, for example, automatically pulling which client is this project from which contact is this related to. But also by connecting it on this end, we can we also automatically connect that from the other end, meaning that when I go through here and I create, let's say, three invoices and connect it to the same project, I'm also going to from the other end be able to see for this project, we have these three invoices. So that's also an important aspect of having that integrated all within monday.com, just using the native functionality. Some other pieces that might be worth mentioning that we can put in here are things like the invoice date, payment terms, the due date can be automatically calculated based on knowing the invoice date and payment terms. And then we also a very common piece that we implement custom when doing these sorts of integrations is a currency converter. So let's say you want to count everything in dollars internally, then you can simply say that this invoice is going to be in this specific currency. And then we load a current exchange rate. Generally, we do this based on the Make piece for this that's already pre built, which is the European Central Bank. But this can also be anything, for example, if you have your own exchange rate list that you want to base this on, that's also entirely possible. But moving on, as you probably also might feel when we're scrolling through this, this is a lot of columns. So generally, what we do, as I recommend most people do when they're working with monday.com and have big tables, is that we can actually open up a single invoice here, and we can implement what's called item cards. So this is an item card, this is still looking at the same columns, but rather than scrolling, vertically back and forth in that table, we can put it into these more nice to look at paints and sort them by different categories. So in this case, I would probably prefer to be in here when I'm creating this invoice. Here I can see some project information, I can put the references in the currency and exchange rate, the invoice values are going to be summarized here for totals, we can still view those invoice line items from this view. And then finally, here we get to the integration specific columns. So the way that we do this integration, generally, what we try to do is to make this in two steps. So number one would be this button right here, which is going to be the create invoice button, which I'll show you in a sec. But what that button does is, as I mentioned, it copies all of this information from monday.com over to our bookkeeping software. So essentially creating an invoice on that end that is exactly going to reflect what we can see right here in monday.com. What we're also generally going to do is when that's been created from the bookkeeping software, it's often based on some form of template with all the branding and whatever it might need. And what we do then is we download that invoice as a PDF copy, and we upload it back into monday.com. So again, going with that principle of the PM shouldn't need to leave monday.com for any part of this process. So they can create the invoice, it will download the copy back to us so that we can preview it. And then in the next step provided that we think that this invoice is exactly what we're looking for, then we can also have a send button generally to send that invoice. And when we click this button, it's not actually monday.com who sends this, since again, the bookkeeping pieces are within the bookkeeping software. We want that to be the master of that data for compliance reasons. So what this button actually does is just send a signal to our bookkeeping software and say, send this invoice to the client. So essentially what we've done is we've taken that user interface that you normally have within that bookkeeping software, and recreated it in monday.com so that you can control everything from here. What we also generally do is for mainly UX purposes or user experience purposes is we often use status buttons or status columns as a button. The reason being that that way we can give some user feedback. In this case, I'm going to click create, and that will automatically update that as soon as Make receives that signal, Make will update that. And then we can also create that into creating to give that user feedback that something is happening in the background. So there we are, Make just received that signal, started working on it. And I know that we're going to get an error here in a second, hopefully. There we are. So what we also do is if we have any information that we can check for, so let's say we have a couple of fields that we know are mandatory, they need to be on that invoice, can be either technically mandatory fields because the invoice software or bookkeeping software won't allow us to create it, unless we've defined them. But it can also be something that we defined ourselves due to policy, we need to fill this stuff in, right? So any of that information we can check for as we're running that integration in Make. And in this case, I purposely didn't fill in the our reference section of this invoice. And then we can update this to error since this is going to be where the user is looking and provide something like this as an example, a text box to even tell the user not just an error has occurred, which is probably the most frustrating error to get, but actually say something like you're missing this specific information, please fill it in and try again. So if we go back up here and put in the Our reference column right here, we can then try again. So this is also an aspect that we're thinking about when we're creating integrations between monday.com and other systems overall, is we want to use those building blocks so that it's still a seamless user experience and the user themselves don't necessarily need to be in the same space. So we need to know sometimes that there is an integration because they're just working in monday.com and doing their thing, right? But now we can see since we fill that in, we got the green crater right here. And we also got a PDF copy right here that we can have a look at. So here's this specific one is in Swedish since it's a Swedish system, but the principle is the same. And here we can also see that the reference I filled in is there. So this is essentially what we try to accomplish with any given bookkeeping software. As a bare minimum, generally, what we also include is that we try to include a link if it's possible. So if we can, we know how that link would look like if you were to actually create it in the bookkeeping software and send it to someone on Slack or Teams so that they can jump straight into the action. We can actually oftentimes put that link back into monday.com as well. So if it would be the case that sometimes the PMs do want to jump into the bookkeeping software to do any final touches, then we oftentimes can also create a navigational link from here as well to quickly jump into it and not have to search for it when they jump into this other bookkeeping software. Super. So that's essentially the core principles of client invoices. As I mentioned, oftentimes it's the case that we also implement some form of sync back from the bookkeeping software to monday.com. So generally, the flow would be that the PM has now done their thing. They're probably going to go in here and just send the invoice, but then they want to still be able to track the status of that invoice. So that's the point where we would implement a sync for if the invoice has been partially paid, paid, or if it's past due. So that way, if the PM is about to, for example, have a check-in with the client and they want to double check that they paid, then they can just go to this board. They will see if it's been paid, if it's been past due, not having to actually talk to finance and wait for them to respond to figure out that information. Super. Moving on then to supplier invoices. And in a second here, we'll look at how the Make portion of this works as well. But first, just quickly go supplier invoices. The core principles are basically the same. The formatting is almost the same since it's still an invoice we're talking about. Main item is an invoice. Sub item are those line items. But the data fields might differ a little bit. Since this is mostly for displaying information rather than changing information. But here we still have that connection to our projects. We still have the copy of the invoice, of course, so that we can preview it from here. Potentially, we have the link to the invoice. And then potentially, as I mentioned, what we often do is we have an approval workflow from monday.com to actually approve the spend on that invoice as well. Super. Moving on then a bit into what this looks like in make.com. So this right here is an example, the one that was just executed as we clicked that button a few moments ago. So this is how a integration like this might look. And again, for those of you who are new to Make, what Make essentially looks like like this is more or less a flow chart with these called modules. And the modules are essentially a single action. Per circle. So in this case, we initially start off with what's called a webhook module. And from the monday.com end, we have webhook modules, which are very similar to the automations in monday.com. If you have ever played around with those, meaning that if I jump into your integrations to just quickly show you here, we have the webhooks button. We have a set of triggers here that can send this signal to Make. So we can be quite specific of when this specifically happens. That's the point we're going to send the webhook to a make.com integration. So in this case, our trigger, as it's called, was when we clicked on this button right here and we click create that specific action, clicking on this column and only clicking on create sends a signal to our make.com flow chart, essentially. So we receive the signal right here. And then we're going to follow this flow. And the first thing that happens here is what I mentioned before. Is that the as soon as make receives that signal, it's going to change from create to creating to provide that user feedback. So I'll open this module up as well to show you what I mean by no code or low code programming. Is that make.com is going to be able to help you out if you want to build something yourself so that you don't actually have to put in the programming behind it. As an example, right here, what's needed to update a column is you need to say which board is it. Which item or row is it? And of course, which column and to what value. But in the background here, the board is actually an ID that looks like this. But what Make is going to do is it's going to help you out here. So it's going to give you a dropdown. And when I click this, make actually goes into your monday.com account and searches to see what boards do we have? What are the titles of that board? Since when we're building, we're generally going to know the board by the title rather than the board's unique file. So that way, in this case, we can select the board. We can select the item, which when I mouse over it, you'll see that the first module here is pulsing. That's simply because this is not going to always be the same one. It's always going to be the client invoices board. But for the row number or row ID, it's going to be different depending on which item did we actually click create on, right? And this is actually information that we get from this webhook module at the start. When we send the signal that someone has clicked this button, we get some information with that as well, including which row, which board, which user, things like that. So this is called just mapping, mapping this specific field to be used for the unique identifier of the row. And then finally, we're going to say in this column to create invoice column, which is the column we have as a button right here, create invoice. We're going to change that to create. So that's an example of how a single module or action can be set up. And an integration is essentially just a flow of these types of actions. But moving on a more high level for the rest of this one, what we have here is a router, which is going to first run this path. And we're going to run this path and finally this path. And these two first paths is essentially our error handling that we looked at before. So what might end up in this box right here? So what we do here, since everything is interconnected in monday.com, is since you have selected the project, then we can dive into that project, can dive into that client, fetch all of that information. And then we can through filters here, check if everything's been filled in as we would expect it to. Again, whether that be for technical reasons, it's required or just due to policy reasons. We want that to be on the invoice. This is going to result in either the text that we just saw before, or when it goes to this path, it's going to check if this has been, if it found any issues. If it doesn't find any issues in the top two trees or branches, it's going to essentially do what it's supposed to do, which is create an invoice. In this case, it's created in Fortnox, which is a Swedish bookkeeping software. But we also have some pre-built modules for other bookkeeping software. For example, QuickBooks being an American one. We have Sage. And we also have some other common bookkeeping systems, I should say, that have pre-built modules. But so if it properly checks everything, everything looks good. You filled everything in. It's going to go in here. In this case, it's going to create an invoice. As you can see here, we only filled out the basics, but generally you can fill in a lot more than we've done in this demo. And then we're going to download that invoice straight from that bookkeeping software and upload it back to monday.com. Super. Moving on a bit then back to monday.com, we're going to have a look at that project overview again, just to kind of tie that back into the whole purpose of this. So we've now looked at what might the client invoice piece look like? What might the supplier invoice piece look like? And now that we have all of that information, we have both client invoices tied to our project and supplier invoices tied to our project. Now we get back to kind of where we started here over to the right. Which is going to be because we have those connections, we can sum those values here in what's called mirror columns. So here we are actually pulling information straight from the client invoices board. And this is pulling straight from the supplier invoices board. So from our project overview where we're actually working on it, we can get both a full picture of what are the planned hours, potentially the reported hours that we can use for our internal costs for that project. We also have the supplier costs of that project. And we have the invoice for that project. So suddenly we have everything we need on this one project item to be able to straight up see what's the full costs and the full invoiced for this project to see was it probably profitable? If no, why? If yes, probably also why? But this is essentially the end goal of all of this beyond simply giving the PMs and the finance people better tools and ways of communicating, not having to do everything via email or Slack or Teams, wherever it might be. They can just do their job as they're supposed to. And the information just flows automatically without really needing much human interaction, getting all of our data placed in one spot. Super. I'll pause there quickly for any questions. Let's see. We're just about running out of time, but I want to make sure if anyone has any questions, we have a couple of seconds to look at those as well. So one question we have is, does this work with any bookkeeping software? So that answer is essentially split into two parts, meaning that the first question is generally going to be, do they have a pre-built module for it? If yes, it's generally simply going to mean that it's going to be quicker for us to build since we get a lot of help with Make. That being said, if they don't have a module, that doesn't mean that we can't use Make for it. It simply means that it's going to take a bit of time to build. It's going to take a bit more time. It's going to be closer to actual programming, but it's going to still help us out a bit. We're still going to be able to use Make for implementing our custom logic on top of that integration. But if you're interested in figuring out, does my specific bookkeeping software have this, then you can also go to the make.com website on the product and apps and services. You can see the entire library of pre-built modules for really any service. And again, this just means that it's going to be quicker for us to build. Quicker, it doesn't mean that if it's not in the list, we can't do it. And that's kind of part two of that answer, which is it's going to also come down to, does the bookkeeping software allow us to integrate with it? Meaning, do they have what's called an open API, which is simply just an interface for us to talk to? Since if we don't have any way to talk with the system, it's going to be really difficult to build any form of integration. So oftentimes, if they don't have a module pre-built in Make my first question would be, do they have an open API? And can I have a look at that API documentation, since that's the way we're going to scope out what can we do and what can't we do? But generally speaking, the example that we just looked at is going to be possible for most bookkeeping softwares with an open API. And another question is, how long does this take to implement? So the example that we looked at, going back to that kind of analogy of fully custom programming, if you build a custom integration from scratch, generally that's going to be measured in months or potentially even years, but often months. When we're building in Make, we're generally going to measure that in weeks. For example, this integration, including both client invoices and supplier invoices, that took us about a week to build, provided that this one we actually created with a specific system that we have worked with before, so it was a bit quicker. Sometimes it might be a bit longer, and oftentimes the first step is either way going to be the scoping process. So first, figuring out what can we do, doing some technical validation on that, and oftentimes, of course, since we develop this for other people, what is this going to actually cost to develop? But generally, we're talking about weeks to build a similar integration to this, again, provided that there's an open API. Super. And I believe that might be all of the questions for today. All right. Thank you, everyone who tuned in. Hope this was insightful. Take care and have a fantastic rest of your day. Bye.