The bolt-on problem
Most eTIMS tools sit beside the ledger. An invoice posts in Dynamics 365. Someone, or a job, sends it to a Control Unit. A second list comes back with CU invoice numbers. At month end finance reconciles the two. Every unmatched document is a compliance exposure and an hour of someone's time.
Bolt-on signing also fails in the places that matter: a credit note that does not point at the original, a POS receipt that sold offline and never queued, a debit note that posted while the CU was down. The ledger looks closed. The KRA file does not. That gap is how groups get surprised.
What in-process signing changes
When the Control Unit call runs inside the posting routine, a document posts only once signed. The signature, the QR data and the CU invoice number land on the same record as the GL entry. There is nothing left to reconcile, because the unsigned document never became a fact.
DigiTaxFlow 365 is built that way on Business Central and on Finance & Operations. Retail and POS receipts sign per transaction, queue offline and sign on reconnect. Credit and debit notes link back to the original. The signed-document report replaces the month-end spreadsheet.
What this means on a multi-country rollout
Kenya is one statutory plug-in, not a reason to fork the template. The chart, the sales order and the POS stay shared. The e-invoicing call is the country layer, the same way PEPPOL or a European SAF-T file is a country layer. If your global design hard-codes "we will bolt eTIMS on later", you have already accepted a second system in the country where enforcement is strictest.
A partner who treats eTIMS as a phase-two interface will hand you a reconciliation. We treat it as a posting rule. That is the difference between a Kenya go-live and a Kenya project that never quite ends.
What to check in your own setup
Ask three questions. Can an invoice post without a signature? Where does the CU number live — on the ledger document, or in another database? How are credit notes linked back to the original? If any answer involves a spreadsheet, the design is wrong.
Then ask who owns the next KRA change. If the answer is a developer and a change request, the signing logic is in code. It belongs in the product. If you want that test run on your tenant, that is a conversation we should have before the next close.