Jordan JoFotara National E-Invoicing

The compliance gap

Jordan's national e-invoicing platform, JoFotara, moved invoicing from a printer to an API. A registered taxpayer submits each sales invoice to the Income and Sales Tax Department (ISTD), receives back a confirmation and a QR payload, and the invoice the customer receives must carry that stamp. An invoice that was never submitted is not a valid invoice, whatever it looks like on paper.

SAP Business One has no Jordanian localisation for this. Businesses running SAP B1 in Jordan generally end up with a manual bridge: post the A/R Invoice in SAP B1, export or re-key it into the platform, get the QR back, then paste or attach it to a document layout by hand. It works for ten invoices a day and collapses at a hundred. Worse, it produces no reliable answer to the only question the tax authority cares about — is every posted sales invoice in this period accounted for on the platform, and does the total agree with the sales tax on your Journal Entries?

ECOSIRE builds an add-on that closes that loop inside SAP Business One.

What ECOSIRE builds

The add-on is a SAP Business One extension that reads and writes your company database through the Service Layer, and uses the DI API where a submission has to be committed alongside a B1 posting. Extension data lives in UDFs, UDTs and UDOs, never in modified standard tables, so your installation stays supportable and upgradeable.

Submission from the documents you already post

A/R Invoices (Invoices), A/R Credit Memos (CreditNotes) and A/R Down Payment Invoices are mapped into the JoFotara payload. The header pulls seller registration data from company configuration and buyer data — name, tax number, national identifier where required — from the Business Partner master. Rows carry item description, quantity, unit price, discount, general sales tax and any special tax, each mapped from the marketing document row so the submitted figures are the posted figures, not a re-typed approximation. Where JoFotara needs a value SAP B1 has no field for, we add a UDF at header or row level and expose it on the form, rather than borrowing an unrelated column.

QR stamp back onto the document

The platform response — confirmation identifier, timestamp, QR payload — is written back to the source document's UDFs and stored in a UDT submission log with the full request and response for audit. Crystal Reports invoice layouts are then built or amended so the QR renders on the printed and PDF invoice your customer actually receives. This is the part that manual bridges get wrong most often: the QR ends up on a separate sheet, or on a version of the invoice that no longer matches what was posted.

A queue that shows the truth

Submission is not assumed to succeed. Every document moves through a visible queue implemented as a UDO: pending, submitted, confirmed, rejected. Rejections carry the platform's reason text, and the document stays flagged until it is corrected and resubmitted, so a failure cannot quietly disappear. A retry service handles transport failures with backoff, and the queue is safe to run with more than one user posting at once — a document is claimed before it is submitted, so the same invoice is never sent twice.

Approvals and controls

Where your finance team wants review before submission, the queue integrates with SAP Business One approval procedures, so an invoice above a threshold or against a flagged Business Partner waits for a decision. Credit notes reference the original submission so the platform can link the reversal to the invoice it corrects.

Reconciliation

We deliver reconciliation reports that answer the audit question directly: posted A/R Invoices with no submission, submissions with no confirmation, and a period summary that ties confirmed submissions back to the sales tax posted in your Journal Entries. These are Crystal Reports, so your accountant can run them without opening a developer tool.

Who it is for

Companies registered for e-invoicing in Jordan that run SAP Business One, and regional groups whose Jordanian entity is on SAP B1 while the rest of the group is not. It is aimed at businesses issuing enough invoices that manual submission has become a bottleneck or a risk, and at those who need a defensible audit trail rather than a folder of screenshots.

Compatibility

SAP Business One 10.0 on Microsoft SQL Server and SAP HANA, on-premise or cloud-hosted. Submission runs against the ISTD's published interface using your own taxpayer credentials — ECOSIRE holds no certification or partnership and does not act as an intermediary; the connection is yours.

How delivery works

1. Scoping call. We review your invoice types, your tax treatment (standard sales tax, exempt, zero-rated, special tax), your Business Partner data quality, and your current invoice layout. Three real invoices become the acceptance tests. 2. Fixed quote. A written scope with field mapping, screens, reports and acceptance criteria, at a fixed price. Nothing is built before you approve it. 3. Build. Typical lead time is one working week from approval. Nothing is pre-built — this add-on is written for your company. 4. Install into test. Installed into your test company database and run end to end against the platform's test environment with your own documents. You get a written test script for your finance team. 5. Install into production. After your sign-off, we install into production, migrate configuration, and stay close during the first live submission day. 6. Support. A support window from go-live covering defects, platform changes published during that window, and your team's questions.

What we do not claim

We are not an authorised agent of the ISTD and we hold no SAP certification. You keep your own taxpayer registration and credentials. What ECOSIRE builds is the SAP Business One side of the connection — accurately mapped, auditable, and tested against your real invoices before it goes anywhere near production.