Request for Guidance on Integrating Manager API with KSA Fatoora E-Invoicing (Phase II)

Your efforts are truly remarkable.
Thank you for your cooperation, and we remain genuinely interested in this topic.

I believe that’s true. but the first question here is: Who is using MAnager as a POS in Saudi Arabia? Even if there are some users, I don’t believe it is widely used in this manner.
I also think the Manager currently does not differentiate between simplified and standard tax invoices. Therefore, we can consider all tax invoices issued by the software as standard tax invoices, not simplified ones. This is essential for creating a custom code or extension to address the current system’s deficiencies and comply with one of the key governmental requirements for system usage.
Every effort made here is a positive step forward, and we hope this goal will be attained soon.

Simplified invoice amount below 1000
Standard invoice or VAT above 1000

This point requires further clarification. According to the Authority, if the invoice amount exceeds 1,000 riyals, the terms of a tax invoice must be followed rather than those of a simplified invoice. This implies that customer (buyer) data must be recorded whether the invoice is B2B or even B2C.

As you are aware, for B2B transactions, it is mandatory to comply with tax invoice requirements and avoid using simplified invoices.

In conclusion, as previously mentioned, we should consider all invoices issued by the Manager as tax invoices. The main determining factors are the invoice amount and the buyer’s details. Currently, the program does not have a separate feature for simplified billing.

@Mabaega great effort. I’m also looking into this. However, my approach would be a bit different. It looks like eventually all countries will have some kind of e-invoicing regulation in place.

And in some cases, it won’t be possible to implement in pure javascript. There will need to be some kind of backend infrastructure in place. So what I’m thinking is to abandon javascript and simply have backend infrastructure in place for everything that needs outside integration.

Therefore e-invoicing could be a web-service that accepts JSON representation of sales invoice in Manager. And responds with JSON representation of sales invoice. This way invoice can be furnished with more information after submission.

This means when someone wants to enable e-invoicing in Manager in any country, all they need is to enter URL of the web-service into Manager (somewhere in Settings tab). If URL of web-service is entered, there can be a button (similar to yours in top-right corner). When button is clicked, Manager will send invoice data to web-service. The web-service will respond with modifications that should be made to the invoice.

I’m considering similar mechanism for bank feeds, tax submission, exchage rate updates etc.

But in the end, I really don’t know which solution is the best. I will have a go at my approach and see how it turns out. In the end, there can be multiple implementations for the same problem.


That’s right, I tried to create a script for this need, but it felt very difficult and I canceled it. Currently I am trying to learn C# and Minimal Api to create a Gateway that is responsible for converting Invoice Data from the Manager into Zatca Signed Invoice and sending it to the Zatca SDK Portal. So far it has worked, although it is still far from expected.


Would you be able to host your code on Github? I think the best course of action would be open source C# library that anyone can use, not just But I’m happy to fund this library on Github for everyone’s benefit. I’m already funding a few open source developers there.

I think we don’t even need that much. Just C# library with a few functions that handle communication with ZATCA servers. No need to figure out how to convert data to ZATCA data. I will do that.


I managed to publish my code to Github. I don’t know how to use Github but I can see all my code there … :slight_smile:


I’ve just released the ZatcaApiGateway on GitHub. It’s not perfect, but it’s ready to be tried out.

Feel free to give it a go and let me know if there are any suggestions or improvements needed.

You can find the release here: ZatcaApiGateway GitHub Release

Thank you!


@Mabaega I’m glad you got working system. Have a look at Relay which is new concept.

This should simplify a lot of things for you but also for end-users. If your e-invocing integration is working as a relay service, all Manager users have to do is to copy URL of your web-service into Manager.


Anyone here in KSA or outside who can advise us or help in the integration process using the new feature Relay would be much appreciated.


I am pleased to inform you that the ZATCA web service is now ready for testing. I hope you can take some time to check its functionality and provide your feedback.

To assist you, I have included a video tutorial that guides you through the process of testing the service. Additionally, you can download the necessary files from our GitHub repository.

Thank you

If you encounter any difficulties while running the web service, please feel free to download the .NET SDK from the provided link.


@Mabaega great progress. We should improve the user experience so there is nothing to download.

For example, can host Relay service for those who don’t want to self-host it. This means Relay service should be generic without business specific configuration as it could be used by many businesses at the same time.

Setting up ZATCA integration should be as easy as copy and pasting Relay URL to Form Defaults of sales invoices and credit notes.

You’ve done a good job on instructions however we will need to find a way how to automate this.

I’ve noticed your project contains SQLite database. What is this database used for?

1 Like

or incorporate it as part of Manager “extension” so it uses Managers .NET SDK.

1 Like

User need adding some Customfields to meet the data requirements.
Users do not need to add custom fields themselves if these fields are already provided in localization.

The webservice needs to store Invoice data that has been successfully reported to Zatca. Store ICV as Invoice Counter and PIH (Previous Invoice Hash) will be used in subsequent Invoice reporting. Stores original data from managers that have been reported to prevent repeated reporting and to restore Manager data if data changes occur accidentally to the Manager. Webservice also stores all responses obtained from the server during reporting. Sometimes invoices that do not meet the requirements will also be accepted with certain Warnings, perhaps this will be useful in the future.

And we also need relays for Payment, Receipts, Purchase and Debit Notes.

I think the data should be stored within file if possible. This would allow to switch to another relay without hassle.

I see, so you need previous invoice hash in order to report the next invoice? Cannot be this queried from ZATCA service?

How come? I thought only sales invoices and credit notes are reported.

Yes it is only for sales invoices, it could be for receipts if customers not using invoices tab

1 Like

ICV and PIH must be from our device, there is no API endpoint to query invoices that we have sent to the Sanbox Portal.

Yes, this is a good idea, but it looks like we will have difficulty querying the last invoice that we sent to get ICV and PIH.

and this for FBR

And this for Malaysia