What should you buy when you commission a JoFotara integration for an existing ERP or point-of-sale system? Buy a defined invoice workflow: an agreed field mapping, controlled credentials, traceable submission outcomes, a recovery procedure, and evidence that finance can reconcile the results. A successful demonstration of one invoice is not an acceptance test for the whole integration.
This guide helps a business owner, finance lead, or procurement team compare implementation proposals. It is not tax advice or a statement that your business must use a particular integration. Confirm your obligations and invoice rules with your accountant and the relevant authority.
Start with the system you already operate
Before requesting prices, record the system name, version, hosting arrangement, support owner, and available interfaces. Does it expose a supported API, an extension mechanism, or a structured export? Where are invoices created, and who can correct the underlying customer and tax data?
Give prospective suppliers a field dictionary and synthetic examples of the invoice types you actually need. Include a correction and a cancellation scenario where applicable. Do not send production credentials, customer records, or a database backup to obtain a quotation.
Your current software may already have a suitable supported connector. For example, Odoo's Jordan documentation describes its own JoFotara module, configuration, and invoice workflow. That is evidence about the documented Odoo implementation, not proof that your installed version includes it or that another vendor supports the same functions. Ask for a demonstration using your version and required document types before commissioning a replacement.
Separate the proposal into four deliverables
| Deliverable | Question the proposal should answer | Evidence to request |
|---|---|---|
| Read source data | How does the connector obtain a stable invoice without disrupting the existing system? | Supported interface, access scope, and sample field mapping |
| Transform and validate | Where are required fields, amounts, and document types checked? | Mapping rules and examples of rejected input |
| Submit and recover | What happens after a rejection, timeout, or interrupted worker? | State diagram, retry policy, and recovery demonstration |
| Reconcile and support | How can finance and support explain an unresolved invoice? | Exception report, reference trail, and named owners |
A single price without these boundaries leaves responsibility unclear. The supplier might demonstrate a successful submission while the source ERP still shows an invoice as unsent.
Decide who owns every field
For each required field, identify its source, business owner, validation rule, and correction path. Do not allow a connector to silently invent a missing tax identifier or change an amount to make a document pass validation.
A useful mapping worksheet has five columns: source field, destination field, transformation, validation, and responsible team. Add an example that fails each important rule. If customer identity comes from the CRM but invoice amounts come from the ERP, document that separation before implementation. The CRM and ERP data-ownership guide provides a way to agree which system controls each record.
Ask the supplier to identify the specification and software versions used in the proposal, with the date they checked them. Our reviewed copy of the government-hosted portal user manual has a cover dated 18/09/2022. It provides historical portal guidance; it does not establish today's API contract, tax rules, or retry behaviour. Obtain the applicable current instructions through the authority before production configuration.
Choose the smallest integration that meets the need
| Approach | When to consider it | Boundary to agree |
|---|---|---|
| Supported connector in the existing system | It covers the required version and document types | Support ownership, upgrades, and documented limitations |
| Separate integration service | Several systems need one controlled submission and monitoring process | Hosting, queue ownership, credentials, and operational support |
| Structured export with a controlled handoff | A supported API is unavailable, and a staged process is acceptable | Manual steps, processing delay, duplicate prevention, and reconciliation |
A controlled export is not a real-time integration. A separate service is not automatically more reliable than a supported connector. Compare the actual workflow and its maintenance requirements, not the architecture label.
Avoid direct database access unless the system owner explicitly supports it and the proposal addresses schema changes, read consistency, permissions, and upgrades.
Treat an unknown outcome differently from a rejection
A local timeout tells you that a response did not arrive in time. It does not, by itself, establish whether the receiving system accepted the invoice. Blindly sending a new document can create an operational duplicate.
Require the design to distinguish known rejection, known acceptance, and unknown outcome. Ask how the supplier will investigate an unknown result using the facilities the actual interface supports. Do not assume that JoFotara offers a particular lookup or idempotency mechanism without verifying the applicable contract.
The local integration should retain a stable source reference and a trace of attempts. An external reference, when available, should be connected to the same record. Define what support does if no reliable final outcome can be established. The invoice-rejection recovery guide covers separating errors that need data correction from errors that need operational investigation.
Test failure paths before signing off
The following is a proposed acceptance checklist, not a list of government-mandated tests. Use an authorised test environment or an isolated simulation. Do not deliberately disrupt production or issue real invoices merely to demonstrate a failure case.
| Test | Expected evidence |
|---|---|
| Required field is absent | A clear error identifies the field and correction owner without exposing sensitive data |
| The same source invoice is processed twice | The agreed duplicate-control behaviour is demonstrated, and the final accounting effect is explained |
| The response is lost after sending | The result remains unresolved until the documented investigation or reconciliation procedure completes |
| The worker stops before recording the result | Restarting follows the recovery procedure rather than blindly creating a new invoice |
| Credentials are unavailable or revoked in a test setup | The system stops safely, alerts the right person, and does not expose credentials |
| A source value changes after submission | The team follows the applicable correction procedure; it does not silently overwrite the accepted document |
Ask to see the evidence, not just a checkbox labelled “tested.” For correction scenarios, agree the allowed workflow with finance and the current specification. The invoice correction and cancellation guide explains why changing the source record and correcting an issued document are separate operations.
Reconcile before expanding the rollout
Finance needs an exception list, not only a green connectivity indicator. Agree which records belong in a reporting period, how statuses are counted, and who owns each unresolved item.
For a fictional rehearsal, suppose the agreed test batch contains 20 source invoices: 17 have confirmed acceptance, two have confirmed rejection, and one has an unknown outcome. All 20 records are accounted for, but the batch is not fully resolved. The unknown item needs investigation; the rejected items need the appropriate correction. These are illustrative counts, not customer results or performance targets.
Reconcile values as well as counts using the applicable rounding and accounting rules. Payment collection is a separate question: an accepted invoice does not prove that money was received. Keep payment references and invoice outcomes distinct, then compare them through the payment-reconciliation workflow.
Make credentials and handover part of the contract
The business should control its authorised accounts and the process for issuing, rotating, and revoking integration credentials. Agree how authorised operators transfer credentials into the runtime environment. Never place them in source code, screenshots, public tickets, or the procurement brief.
Require a handover that another authorised operator can use:
- Supported versions, field mapping, and configuration instructions.
- Deployment, backup, recovery, and rollback procedures.
- Monitoring definitions and a named response owner.
- Acceptance evidence and a record of unresolved limitations.
- Source-code or package ownership, access rights, and documentation.
- Warranty boundaries and responsibility for future specification changes.
A support contract should say who investigates a failed invoice, who corrects source data, and who maintains the connector after either connected system changes.
Compare total cost, then agree a limited pilot
Compare discovery, implementation, testing, hosting, training, support, and upgrade work separately. Ask whether pricing depends on branches, environments, document volume, or licences. A low initial price may be reasonable for a narrow scope; it is not comparable with a proposal that includes ongoing reconciliation and support.
Before expanding, agree a limited pilot, the records it covers, the review owner, and the criteria for stopping or proceeding. Confirm how the business will continue operating if the integration needs investigation. Do not assume a manual fallback is legally or operationally acceptable without checking it.
If you need a connector around an existing system, review our JoFotara integration service. To discuss a practical scope, send a project brief with the system version, required document types, and synthetic examples. Leave credentials and customer data out of the initial enquiry.
