We File to KRA Automatically. We Do Not Talk to IFMIS.
Every public tender has an integration line, and it is usually answered with a yes. Here is our actual answer: we file to KRA automatically, against real endpoints, with the receipt number stored on the record. We have no connection to IFMIS of any kind. The difference between those two answers is structural rather than a matter of effort, and understanding it is worth more than either answer on its own.
There is a line in most public tenders that reads something like "the system shall integrate with existing government financial systems", and the honest response to it is a question rather than a yes. Which system, in which direction, and which one holds the authoritative number? Vendors who answer yes without asking that are usually planning to produce a CSV export and call it an interface.
We can give a precise answer, because our position is unusually clear-cut. We have one live integration with a Kenyan government system, it runs automatically, and it is not IFMIS. We have no connection to IFMIS at all — no interface, no export format built for it, no mention of it anywhere in the product.
What makes that worth a whole post is why. The two are not different by degree of effort. They are different in kind, and the difference tells you something useful about how to specify your own integration requirement.
What we do file, and how
Electronic tax invoicing to the Kenya Revenue Authority is built and it is automatic. Not a report you generate, not a file you upload — a document that is submitted as a consequence of a sale being recorded.
| Aspect | How it works |
|---|---|
| What is filed | Point-of-sale sales, customer invoices and subscription invoices, each with its own mapping |
| When | Automatically when the record is created, queued after the transaction commits |
| Why queued | So that recording a sale is never blocked or slowed by the tax authority being unavailable |
| Safety on retry | Idempotent — a retry does not produce a second filing |
| Manual filing | A button exists and reconciles with the automatic path rather than competing with it |
| Environments | Separate sandbox and production endpoints at the authority's own domain |
| Setup | A device initialisation step, and a test invoice you can push end to end against the sandbox |
| What comes back | Receipt number, receipt signature, internal data, QR code URL and the filing timestamp — all stored on the record |
| When it fails | The error is stored on the record with a status, so a failed filing is visible rather than silent |
That last row is the part that distinguishes a real integration from a demonstration. Anything can succeed on a good day. What matters is whether a failure is stored somewhere a person will find it, and whether the transaction that triggered it went through regardless. Both are true here: the sale is never held up by the filing, and a filing that did not succeed carries its error.
What we do not do
There is no IFMIS integration. There is also no interface to any treasury system, no connection to a public e-procurement portal, and no regulator filing of any kind beyond the tax one described above. Searching the entire application for any of them returns nothing.
That is a complete answer rather than a hedged one, and it is deliberately stated that way. If your requirement is that procurement data flows into a government financial system, the correct thing for you to know before a procurement decision is that this product does not do it and no configuration will make it.
One of these systems needed a published specification and a credential. The other needs an agreement about who owns the number.
Why one was possible and the other is a different kind of problem
It would be convenient to say the tax integration was easier. It was not especially easy. It was tractable, and these are the four properties that made it so.
It has a published specification and a sandbox
There is a documented interface, there are two environments, and a vendor can build against the test one and prove the round trip before touching anything live. Without that, an integration is not engineering; it is negotiation.
The credential belongs to the business, not to us
Each organisation holds its own registration and initialises its own device. We are not a gatekeeper and we are not reselling access. That means the integration scales to every customer without anybody negotiating on their behalf.
It is one-way
We push a document and receive a receipt. Nothing flows back that changes our records. This is the property that makes the integration safe to run automatically thousands of times a day: there is no state to reconcile, because only one side is asserting anything.
It makes no claim over anything we hold
The tax authority is authoritative about tax. It is not authoritative about your stock figure, your budget or your supplier list. We tell it what happened; it does not tell us what is true.
That last point is where an integration with a government financial system differs fundamentally. Such a system is authoritative over exactly the numbers a buyer would want synchronised — the vote, the commitment against it, the payment. An integration that is useful has to be two-way, and the moment it is two-way, somebody has to decide which system owns the authoritative figure at each moment.
The failure mode worth naming
Two systems that both believe they hold the authoritative commitment figure is worse than no integration at all. With no integration, everyone knows which record to trust and reconciles deliberately. With a half-defined two-way sync, both records look authoritative, they diverge quietly, and the divergence is discovered by an auditor rather than by a finance officer. That risk is the reason we have not built towards this on speculation.
The question that decides your architecture
If a government financial system holds your vote and your commitments, then any operational product you buy sits downstream of it. That is not a limitation to work around; it is the correct shape, and it makes the specification much easier to write once you accept it.
What an operational product should own
- What physically arrived, in what quantity and condition
- Where stock is, batch by batch and location by location
- Who holds which asset, and every change of custody
- The supplier register and its qualification lifecycle
- The day-to-day request, quotation and order trail
- Counts, variances and the evidence behind an adjustment
What the financial system of record should own
- The vote and its ceiling
- The authoritative commitment against it
- The payment and its authorisation
- The statutory financial reporting position
- Anything an auditor will treat as the official figure
Written that way, the integration requirement usually shrinks. What most public entities actually need is not a live two-way sync — it is a reliable, dated, exportable account of the operational facts, in a form the finance team can reconcile against the official record on a cadence.
What exists today to make that boundary workable
There is a documented public API, and being precise about its shape matters more here than anywhere else in this post.
- It is read-only. Four scopes — an umbrella read scope, and narrower ones for inventory, sales and procurement. Inventory covers items, categories and warehouses; sales covers customers and customer invoices with their line items; procurement covers suppliers and purchase orders with their line items.
- It supports incremental synchronisation. A parameter takes a timestamp and returns only records changed since, so a nightly pull does not re-read everything. An unparseable value is rejected rather than quietly ignored.
- It paginates, twenty-five per page by default and a hundred at most.
- Its failures are legible. Distinct responses for an unknown or revoked key, a key without the required scope, a record that does not exist in your organisation, a malformed parameter and a rate limit — so an integration can tell a permanent problem from one worth retrying.
- It never leaks across organisations. A record belonging to somebody else returns the same not-found response as one that does not exist, so the API cannot be used to confirm that an identifier exists elsewhere.
Read that list again with the emphasis on the first line. You can pull operational data out of this product on a schedule, reliably and incrementally. You cannot push anything into it through that interface. If your intended design has a government system writing into this one, that path does not exist today.
-
Name the system, not the category
An integration requirement that says "government financial systems" cannot be answered honestly by anyone. Name the system and the direction and the answer becomes checkable.
-
Decide who owns each number before you decide on software
The vote, the commitment, the payment, the stock figure. Write down which system is authoritative for each. Most integration disputes are this argument, unhad.
-
Ask for the direction in writing
"Integrates with" covers a one-way nightly export and a live two-way sync equally. They are different products. Insist that the tender response says which.
-
Treat reconciliation as a designed process, not a fallback
A dated, incremental pull into a reconciliation the finance team owns is a robust design. It is also what most "integrations" turn out to be, once you look.
-
Check the failure behaviour of anything automatic
Ask what happens to a transaction when the far end is down. If the answer is that the transaction fails, that is a design decision you will feel on your busiest day.
Built and verified in the code
- Automatic electronic tax invoicing to KRA, covering point-of-sale sales, customer invoices and subscription invoices, each with its own mapping.
- Filing is queued after the transaction commits, so recording a sale is never blocked or delayed by the authority being unreachable.
- Idempotent submission, reconciled with a manual filing button rather than competing with it.
- Separate sandbox and production endpoints at the authority's own domain, with a device initialisation step and a test invoice you can push end to end before going live.
- The response stored on the record — receipt number, signature, internal data, QR URL and the filing timestamp — and the error stored when a filing fails, so failures are visible rather than silent.
- A documented read-only public API with scoped keys, pagination, incremental synchronisation by timestamp, and distinct, retryable-or-not failure responses.
- Cross-organisation safety on that API, where another organisation's record is indistinguishable from one that does not exist.
Not built — verified absent
- No IFMIS integration of any kind. No interface, no export format built for it, and no reference to it anywhere in the application.
- No treasury system interface, no public e-procurement portal connection, and no regulator filing beyond the tax one described above.
- No write access through the public API. Every scope is read. Nothing external can create or modify a record through it.
- No two-way synchronisation with any external financial system, and therefore no conflict-resolution rules, because there is nothing to conflict.
- No commitment or budget data exposed through the public API. The read scopes cover inventory, sales and procurement records, not budget consumption.
Where the line falls
- If you need automatic tax filing on sales and invoices, that exists, runs by itself, and stores its evidence on the record.
- If you need operational data pulled into a finance system on a schedule, the read API is built for exactly that and supports incremental sync.
- If you need a government financial system to write into this product, or a live two-way commitment sync, that does not exist and we would want a long conversation about who owns which number before agreeing to build it.
A push interface — letting an external system create or update records under a scoped, audited credential — is buildable and well understood. What we would not do on a fixed price is a two-way commitment synchronisation without first agreeing, in writing, which system is authoritative at each moment. That agreement is the actual deliverable; the code is the easy part.
Verified against the repository on 7 August 2026. The absence of every other government interface was established by searching for each by name.
The useful thing a vendor can say about integration is not yes. It is here is the one we have, here is precisely why it works, and here is the property your other requirement has that makes it a different conversation. A public entity that gets that answer can write a better specification, whoever they end up buying from.
Name the system and the direction
If you have an integration line to satisfy, tell us the system, which way the data moves and which side is authoritative. We will tell you plainly whether it exists, whether the read API covers it, or whether it is a build — and we will say so before you commit to anything.
Talk to us about integrations