Government Procurement & Tax Automation

Sanitised and conceptual. This describes the shape of the problem and the engineering approach in generalised terms. It is not a representation of any employer’s proprietary architecture, source code, data or internal metrics.

Context#

Two points in my career, seven years apart, sit in the same domain, and the pair of them frames the whole progression.

In 2017, at Myrior Solution Ltd, I developed the front end of the Osun State Public Procurement Portal in Laravel, CSS and JavaScript, and worked the QA, deployment and feedback-integration cycles behind its releases. In 2023, at Centric Platform, I was building the backend systems for the PAYTAX ABIA and PAYTAX IBEJU government tax automation projects, including an automated tax compliance model using NLP to extract key insights from financial data in Python, alongside scalable Node.js microservices for Abiapay.

Same domain. The first time I was building what citizens saw; the second time I was building what the state relied on.

The engineering problem#

Public-sector software has two properties that reshape every design decision.

The audience is everyone. Nobody self-selects into using a procurement portal or a tax system. There is no power-user cohort to carry the awkward parts of the interface, and no option to assume technical patience.

Correctness precedes convenience. In a consumer product, a wrong result is an annoyance to be fixed in the next release. In a tax system it is a citizen owing the wrong amount of money. That single fact is why automation in this space has to be built as assistance rather than authority.

What I owned#

• Built an automated tax compliance model using NLP for extracting key insights from financial data, in Python.
• Delivered the backend systems for the PAYTAX ABIA and PAYTAX IBEJU government tax automation projects.
• Created scalable microservices for Abiapay using Node.js, and spearheaded system maintenance and feature enhancements.
• Developed the front end of the Osun State Public Procurement Portal in Laravel, CSS and JavaScript, and participated in QA testing, deployment and feedback-integration cycles to ensure release quality.

Conceptual architecture#

Tax compliance automation, conceptual processing path

1. Intake

   • Financial documentsUnstructured input
   Parse

2. Extraction

   • NLP pipelinePython
   • Structured fieldsNormalised output
   Propose

3. Control

   • Human reviewApproval gate
   Commit

4. System of record

   • Compliance backendAuthoritative store
   • ReportingProgramme oversight

Engineering considerations#

The review gate is structural. An NLP model extracting figures from financial documents should propose, never decide. Drawing human review as an explicit stage between extraction and the system of record is not caution, it is the design. Removing it would change what the system is.

Extraction confidence has to survive the pipeline. A model that reports how certain it is, and a pipeline that throws that signal away before a human sees it, is worse than no model: it produces uniform-looking output of non-uniform reliability. Confidence needs to reach the point of decision.

Auditability is a requirement, not a feature request. Public money implies a question that will eventually be asked about any individual record: where did this number come from? A system that cannot reconstruct that chain has a problem that no amount of accuracy compensates for.

Accessibility is the baseline in public software. Building a government procurement portal early taught something that has stayed useful: when your user base is an entire state, the assumptions you are allowed to make about devices, connection quality and familiarity shrink to almost nothing.