Services · JoFotara integration
JoFotara integration for a live billing system. We build a JoFotara connector around the billing system you already run: we do not replace a sound platform for the connector alone, and we do not sign into the Department portal as you.
The service is for an establishment that already has invoices and needs submission to JoFotara with an explicit rejection path. We write the event contract, persist responses, stop a duplicate number on timeout, and train the operator on the rejection screen so a non-developer can resubmit after the source is corrected. Credentials are created on the official portal and stay with the taxpayer. BarmajTek does not accredit anyone and does not sign in as the establishment. If the invoice already leaves a ready clinic consult, start from Clinic Tek rather than an unnecessary parallel connector. If the current system is sound, this is a submission-layer contract, not an accounting rewrite.
Copy reviewed on 2026-08-26.
In operations
The current system stays
The connector is a layer around the issued invoice. We do not rewrite accounting for an authorization header.
Rejection is part of delivery
We do not close scope on “successful submit”. The operator sees the reason and resubmits after the source is corrected, and the response is stored for matching. If only the developer can correct it, the till stops on the first busy day.
Secrets stay with the taxpayer
Client-Id and Secret-Key come from the portal. We bind them in runtime configuration and do not publish them.
No accreditation badge
The Department does not run an approved-vendor list for invoicing software. We sell engineering work.
The integrations hub covers JoFotara, payments, and delivery together. This page is only the Jordan national invoicing path: a clearer scope, rejection examples, and links to the developer and registration guides. If you are building a new platform from scratch, fold the connector into SaaS development instead of a separate adapter contract.
The invoice families the taxpayer actually issues, the source of each field, a submit identity that does not repeat, timeout behaviour, the rejection screen, and daily matching with accounting. We write who corrects the source on rejection, where the full response is stored, and what the till sees without secrets. Out of scope unless written: redesigning the till, a tax ruling, an invoicing connector outside Jordan, and scanning a paper archive. If discovery shows the invoice is built twice in two systems, one source is chosen before any submit.
One accepted invoice, one rejected invoice a non-developer can fix, and a timeout that does not mint a second number. We replay that scene in front of the till operator, not only the developer. If no trial environment exists on your account, we agree with the accountant on the smallest lawful test document, and we record that the document is not a promise of a public sandbox. We do not invent a public sandbox URL, and we do not call the work done after one green submit in a quiet office.
If the invoice already leaves the ready product, read the clinic JoFotara page and pricing, then the product host. The connector project fits teams that stay on another sound billing system.
Price follows how many document families and failure cases must be proven, not a vague “interface hookup”. We quote after inventorying the system, trial access, and who is allowed to correct a rejection. This page does not invent a dinar figure, and it does not copy Clinic Tek subscription prices onto a connector contract. If the family count changes after discovery, the quote changes in writing before build.
No JoFotara certificate from the Department, no Saudi e-invoicing connector, no dinar fine, and no mandate timetable copied from a vendor blog. The technical guide and the educational articles state the same limits.
We start from the current billing system and rejection cases. Send a brief after reading the registration guide if the portal is not linked yet.
