Introduction

Salesforce is the world's leading customer relationship management solution. It's one integrated CRM platform that gives all company departments — including marketing, sales, commerce, and service — a single, shared view of every customer.

Salesforce provides a central place for businesses to store customer and prospect data, track customer interactions, and share important information between departments. It gives businesses a 360º view of their customer, capturing their interactions with the business and helping organisations streamline processes, build customer relationships, increase sales, improve customer service, and increase profitability.

Being a cloud-base solution makes it really easy to get up and running, allowing teams from different geographies to start working together without significant up-front infrastructure and maintenance costs. Finally, since it is priced according to the number of users who access the system It’s also extremely flexible, enabling scaling simply by adding more people to the system as the business grows.

Another great feature of Salesforce is that besides its core product, there are several other applications that can easily be bought and installed which fill the gap that standalone traditional CRM applications have in terms of other functionalities that are not the core of a CRM tool. One example is automating billing processes like invoicing, which could be done via other software installed from AppExchange, the Salesforce App Store, that can add ERP functionalities to Salesforce. .

In this article we will explore how one of our customers, with the help of WorldIt, leveraged Salesforce and FinancialForce (a product available in AppExchange) Accounting module to build an integration with an Invoicing System that allowed them to issue valid invoices to its customers.

Context

The above-mentioned customer is a technological and innovative company developing a platform for leasing equipment to small and medium enterprises. It leverages FinancialForce capabilities not only to ensure correct bookkeeping of its financial transactions, but also to automate billing processes like the issuance of invoices, credit notes, trak payments, among others.
However, despite its capability of generating invoices and other commercial documents directly for Salesforce, FinancialForce is not recognized by the Portuguese tax authorities as an invoicing system, which means that these documents are not legally binding and cannot be used as proof of the debt.

The certification of an invoicing software depends on the cumulative existence of a set of requirements approved by dispatch of the Director General of the Taxation and Customs Authority. These requirements include things such as:

• Allowing exporting the SAF-T-PT file with the legal layout at the time.
• Allowing identification of stored invoices or equivalent documents and receipts, through an asymmetric cipher algorithm and a private password, which is only known by the program producer;
• Not allowing that on a signed document, any relevant fiscal information be changed as referred on articles 36 and 40 of Portuguese Tax Code and on the 6th and 7th article of the Portaria 340/2013
• It must also be stored the version (integer sequential number) of the private key used to generate the signature of the document
• The software display screens must all be available in Portuguese, it is possible for the software to be multilingual but the Portuguese translation must be insured.

Besides all the requirements that must be respected, the process of validating the system by tax authorities is bureaucratic and has several phases. Given the foregoing and taking in consideration the considerable effort of building on top of FinancialForce core functionalities, the customer decided to integrate its Salesforce instance with an invoicing system, in this case Moloni, that would be responsible for receiving invoice data from Salesforce and creating the invoices, respecting all tax authorities impositions. This approach allowed the customer to not only avoid a huge customization project that would take several months to complete and would consume most of its resources, but also to avoid having to maintain a product that is not the core of its business, and go through the process of having it approved by the Portuguese Tax Authority.

Implementation

As described in the previous section, the client decided to integrate its accounting system, composed by Salesforce and FinancialForce, with Moloni which is a cloud based billing software that exposes a Rest API allowing seamless integration between the 2 systems. That API, provides a set of endpoints for different operations and accepts HTTP requests via the POST method, which after authenticating through the oAuth protocol, returns responses in JSON format.

With the approach, depicted below, Salesforce would be responsible for identifying, not only which clients to invoice but also what should be invoiced and create those records (Sales Invoices). Then, when the documents were posted (deemed complete), Moloni API would be called so that those invoices info would be integrated on that system. After that, a batch process would run on Salesforce calling another Moloni API endpoint to get the Invoices PDFs, store them in salesforce under each document and send them to the clients via Email.

Invoice Creation and Integration

As depicted below, the process starts by identifying, creating and completing the Sales Invoices in Salesforce.

Each Invoice consists of a header with the invoice dates and the identification of the client and a set of line items with the name of each invoiced product, together with its quantity, unit price and tax code.

For each completed invoice the system gathers all the required information, builds the JSON request and integrates the invoice info in Moloni by calling the corresponding endpoint. Unfortunately (as it can be seen in the documentation), Moloni only allows the integration of one invoice at the time meaning that, due to this limitation, the Salesforce batch process described here has to run with batch size = 1.

Furthermore, during the integration process neither the invoice total nor the product names are sent. Instead, for each line item, the product Id, together with the quantity, unit price and Tax Id are sent and then computed by Moloni. Given the foregoing and in order to allow this correlation between the systems the following had to be guaranteed:

1.     Product and Tax code info setup in Moloni

In order to allow Moloni to generate the invoice line items, we needed to set up both the product list and the available tax codes that would allow the application of the correct VAT according to the client’s tax zone.

Regarding the product setup, as it can be seen in the images below, this can easily be done by manually adding articles under a previously created category.

Moloni allows setting default values for the unit price and VAT tax code, which in this case can be disregarded as the invoices are all created via Webservice, meaning that the unit price and quantity will always be sent.

In Portugal, as in many other countries, there are different VAT rates which vary not only according to the goods being selled, but also to the buyer and seller locations. Therefore, as the customer described in the present use case does business in Portugal mainland, Azores and Madeira, different tax rates had to be in place, so that the invoices could be correctly generated.

Similar to what was done for the products, Moloni provides a simple interface for creating the different Tax Codes and associated percentage value.

It’s important to mention that Moloni API also exposes methods to create and administer products and tax codes. However, given the low amount of products and tax codes within the client’s core system (Salesforce) this integration was not developed and the management is done manually, as described above.

2.     Store the corresponding IDs on Salesforce

Having both the products and the tax codes setup in Moloni we now needed to store this data in Salesforce. To achieve this two new fields were created, one at the product and the other at the product tax code level, allowing us to store the Moloni Ids on the corresponding salesforce records.

As it can be seen in the following images, the Moloni_Prod_ID__c and Moloni_TAX_ID__c salesforce fields are populated with the Id from the corresponding Moloni record.

Having all the products and tax codes created in Moloni and having those record Ids mirrored on Salesforce, we were now able to easily build, from each Sales Invoice, a JSON request with all the mandatory info that is needed to integrate it. Then, for each successful invoice integration, Moloni returns the Id of the invoice on that system. This Id is then used to update the corresponding Sales Invoice on Salesforce which is also marked ready to be sent to the client.

PDF Generation and Client Notification

Having the Sales Invoices created in Moloni, the next step of the process would be to send them to the clients. For this purpose we’ve developed a batch process that would run on Salesforce calling another Moloni API endpoint to get the Invoices PDFs, store them in salesforce under each document and send them to the clients via Email.

As depicted above the process starts by identifying which are the invoices that are already integrated in Moloni and that were not yet sent to the clients. Then for each of these invoices the documents/getPDFLink is called, allowing us to retrieve the link from where the requested document can be downloaded.

The image above shows the document’s download page that can be accessed through the previously retrieved link, as well as the download URL for the document. As it can be seen, using the info retrieved from the documents/getPDFLink endpoint we are able to easily build the document’s download URL. Then, setting this download URL as endpoint in a simple HTTP GET request we are able to obtain the document’s Base64, which after being converted into a Blob thought a OOTB Salesforce method (getBodyAsBlob), can be used to create an attachment in Salesforce which will be then associated with the respective sales invoice record. Finally, in the last step of this process, Salesforce builds and sends an email to the client containing both the invoice details and the invoice PDF attached.

As it can be seen in the image below, after the process is finished, we end up with the invoice record updated with both the attachment and the email sent to the client allowing us, not only to visualize the invoice PDF, but also to have a track history of what was sent to the client and when.

Conclusion

As previously mentioned, despite its capability of generating invoices and other commercial documents directly from Salesforce, FinancialForce is not recognized by the Portuguese tax authorities as an invoicing system, which means that these documents would not be legally binding. Furthermore, since the certification of an invoicing software is bureaucratic, has several phases and depends on the cumulative existence of a set of requirements, the customer decided to integrate its core systems with Moloni, which is a cloud based billing software certified by the Portuguese Tax Authorities. Being a modern software, it exposes a Rest API which allowed WorldIt, together with the Customer team, to fairly easily integrate it with Salesforce allowing seamless communication between systems.

This approach turned out to be the best option as it not only allowed cost savings, since the software licenses were not expensive, but most importantly, allowed the Customer to shift its limited resources to the development of product features that were the core of its business. Furthermore, it released the development and process teams from the burden of having to analyse and develop new functionalities in order to comply with new regulations that might be released by the Tax Authorities. On the other hand, it is important to mention that following this approach also brings some challenges and limitations that should be taken in consideration when choosing to delegate some features of a product to a third party Software. In the present case being dependent on a third party not only forced us to adapt the processes to fit that software available features, but also limited our ability to customize our communication with the clients as the Invoice PDFs were not generated by us.