Further Clarity on the e-Invoicing Process

Ams

@SysAdmin , i have a few clarifications to make:
My role in the ecosystem is a System Integrator.

will it be correct to say that the flow of data(invoice) is always in one direction? i.e the process always start from the Merchant(Seller) and the invoice ends up at the buyer's invoicing system? and not the other way round (i.e not bi-directional)?
In some of the discussions i've read, i see instance where it wad mentioned that the Merchant can decide to reject an invoice? or accept? i'm not too clear on what that implies. At what point can they reject and not reject? An invoice that was sent by a merchant which got to the buyer's system has a status of pending, does it mean until the merchant updates the status of invoice as paid before FIRS "takes the invoice into account".?
Part of the roles of an SI is to generate QRcode that can be validated, will it be correct to say that the purpose of scanning and validating the QRCode is to ensure that the IRN is in the right format and it's coming from a registered taxpayer(because the IRN has the service ID, the cryptographic keys - all of which are used in the encryption and are all tied to the taxpayer) OR is the purpose of scanning and validating the QRCode to verify that the Invoice has gotten to FIRS and it's certified and signed? depending on your response will assisting in knowing if validating the QRCode is highly dependent on validating and signing the invoice schema.
as a system integrator, does it mean for every of our client we'll need to schedule a demo to do a workaround of the system or it's a one time thing?

SysAdmin

Dear @Ams,

Please find our responses below:

will it be correct to say that the flow of data(invoice) is always in one direction? i.e the process always start from the Merchant(Seller) and the invoice ends up at the buyer's invoicing system? and not the other way round (i.e not bi-directional)? Not correct, you also need to create a framework for accounts receivable coming through the business Access Point Providers (APP)
In some of the discussions i've read, i see instance where it wad mentioned that the Merchant can decide to reject an invoice? or accept? i'm not too clear on what that implies. At what point can they reject and not reject? An invoice can be rejected by the supplier if the underlying transaction did not materialize. This action can be performed at any time, provided that no payment has been made on the transaction.. An invoice that was sent by a merchant which got to the buyer's system has a status of pending, does it mean until the merchant updates the status of invoice as paid before FIRS "takes the invoice into account".? All invoices are taken into account by FIRS. However, only invoices with a “Paid” status form the basis for determining the supplier’s tax liability.
Part of the roles of an SI is to generate QRcode that can be validated, will it be correct to say that the purpose of scanning and validating the QRCode is to ensure that the IRN is in the right format and it's coming from a registered taxpayer(because the IRN has the service ID, the cryptographic keys - all of which are used in the encryption and are all tied to the taxpayer) OR is the purpose of scanning and validating the QRCode to verify that the Invoice has gotten to FIRS and it's certified and signed? depending on your response will assisting in knowing if validating the QRCode is highly dependent on validating and signing the invoice schema. The QR Code serves as an additional security layer on the rendered or printed version of the invoice. Its primary purpose is to prevent bad actors from tampering with invoice details. Regardless of any attempted alteration, the IRN (Invoice Reference Number) will always return the original, authenticated invoice data.
as a system integrator, does it mean for every of our client we'll need to schedule a demo to do a workaround of the system or it's a one time thing? No, you are only required to conduct the demonstration in your capacity as a Service Provider.

Ams

Thank you for your response @SysAdmin ,

as for (1.) is it a requirement to have completed that framework before we schedule our demo? because from my understanding we'd need to connect with an APP to be able to achieve that. However at this point , we're only onboarding as a system integrator. KIndly let me know if it's a requirement to have already integrated with an APP before we'll be able to proceed with our demo with FIRS.
Currently, we have:

Standardized the invoice schema,
Validate the invoice schema json data (on the portal) coming from the ERP
generate IRN
validate the IRN (on the firs portal)
Generate QRCode
Validate the QRCode using the MBS360 app

Kindly let me know if there's anything missing to proceed with the demo for us to be certified as a system integrator

Thank you.

SysAdmin

Dear Ams

Please see the requirements for demo here: https://community.firsmbs.com/d/140-demo-for-firs

Ams

For System Integrators (SI):
Thank you for your response, i have reviewed the requirement you directed me to

I have a concern on this part of your response:

_>
You are required to:

1. Demonstrate the ability to generate an IRN and QR Code that can be successfully validated.
2. Ensure that the payload structure strictly conforms to the published schema.
3. Set up mechanisms for data interoperability (inflow & outflow)

Please refer to the API documentation page for the relevant endpoints and technical specifications needed to achieve the above.

_

i need clarity on point no.3 "Set up mechanisms for data interoperability (inflow & outflow). ? what is expected of us to do as a system integrator on this point. and do we need an APP to be able to do complete this process before scheduling our demo?

SysAdmin

Ams You do not need to have an APP before scheduling your demo. However, data inflow and outflow must be adequately taken care of within your architecture.