Sometimes the Regulated Thing Is the Software, Not the Invoice
Almost every tax rule you will meet describes a document: what it must name, which figures it must show, when it must be sent. A few describe the program that issues it. That is a different kind of requirement, it cannot be satisfied by shipping a feature, and the check for it takes two minutes and almost nobody runs it.
A software shortlist is a list of things a system can do. That framing works for almost every requirement anybody puts on it, including the tax ones — can it handle more than one rate, can it produce the return, can it show the customer's identification number on the face of the invoice. All of those are capability questions, and a capability question has the useful property that a demonstration can answer it. Then occasionally you meet a requirement that a demonstration cannot answer at all, because it is not a statement about what the software does. It is a statement about what the software is.
We ran into one of these writing a country page, and it changed how we think about the whole exercise. It is worth setting out properly, because the failure mode is not that a buyer gets the wrong answer. It is that they never ask the question, complete a perfectly rigorous evaluation, and discover in month three that the winner was ineligible before the evaluation started.
Two kinds of rule
The first kind, and by a wide margin the more common, is a rule about the document. It says an invoice must carry particular things — the parties, their identifiers, the date, a description, the tax shown a particular way — and it says when and how the document has to reach the other party or the authority. Rules of this kind are satisfied by any system that prints the right things in the right places. They are pure capability. If your software does not do it today, that is a gap, and a gap has a price and a date.
The second kind is a rule about the program. It says that the software issuing the document must itself have been submitted to the tax authority, assessed against published requirements, and entered on a register — and that documents it produces carry the reference from that register. The distinction is not one of degree. A rule of the first kind asks whether your system can be made to comply. A rule of the second kind asks whether your system has been permitted to participate, and the answer is not held by the vendor. It is held by the authority, in public.
A capability gap is a question about what a vendor will build. An accreditation gap is a question about what a regulator has decided. Only one of those has a price, and a procurement process that treats them the same will price the wrong one.
Portugal, as the worked example
Portugal is the clearest case we have looked at, which is why it is here and not a hypothetical. Businesses established there are required to issue invoices from software certified by the tax authority — subject to conditions we will come back to — and the authority publishes the register of certified programs, searchable by anybody, so that a taxpayer can check the software they use or are about to buy. That register is the answer to the question. Not a vendor claim, not a compliance page, not a badge on a website.
Around that sits a set of obligations that are themselves interesting, because they are the reason certification exists rather than a badge for its own sake. Document series are communicated to the authority in advance and it returns a code for each one. Every invoice and other fiscally relevant document carries a unique document code built from that code and the document's own place in the series, alongside a machine-readable code to the authority's specification. The billing records go to the authority monthly, by the fifth of the following month. Each of those is enforceable only if the program producing the documents is a known quantity — which is what the certification makes it.
The condition that is not the one everybody quotes
The obligation is usually explained with a turnover figure: businesses established in Portugal that turned over more than fifty thousand euros in the previous year must use certified software. That is accurate, and on its own it reads as an exemption for everybody smaller. It is not the only condition. The professional body for certified accountants sets them out as a group, and another of them catches anyone who uses invoicing software at all, with a further one for businesses required to keep organised accounts or who have opted into them. Read together they close the gap that the figure alone appears to leave open: choosing to raise invoices from software is itself one of the triggers, and what remains available below the threshold is paper from an authorised printer, or issuing directly on the authority's own portal. Whether any of the conditions applies to a particular business is a determination for its accountant, and this post is not making it.
Portugal is not unique in this, which is the reason to care about the category rather than the country. Several jurisdictions require a fiscal device, a registered or approved application, or an accredited transmission agent standing between a business and the authority. What varies is how visible the requirement is to somebody running a software evaluation from outside the country — and Portugal happens to be unusually transparent about it, because the register is public.
Where this leaves us, stated in the first person
We are not a certified invoicing program in Portugal and we do not appear on that register. We publish that on our own country page in the first paragraph, because writing a market page that buries it would be the exact failure this post is about.
The part worth setting out is the shape of the distance, because it is not what "no" usually means and the difference cuts both ways. When we went through the four obligations against our own code, three of them turned out to be much closer than we expected. Our sales documents already draw their reference from a counter held per organization and per year under a lock, which is structurally what a registered series is, minus the registration. Our invoice template already renders a tax authority's machine-readable code, in vector, from a stored payload — beside a receipt number, a receipt signature and a timestamp that authority returned. That is Kenya, it is live, and the same components would draw a Portuguese one. So the engineering is ordinary work of a kind we have done before, for one authority, in production.
| The obligation | What kind of problem it is for us |
|---|---|
| Documents issued from a registered series | Engineering. The counter beneath it is already the right shape. |
| A unique document code and a machine-readable code on each document | Engineering. The rendering exists and is in production for another authority. |
| Billing records to the authority monthly | Engineering, and the largest of the three. Our invoice export is seven columns of header data with no lines, rates or tax codes. |
| The program itself certified | Not engineering. An accreditation granted by the authority against its own requirements, recorded on a public register. |
That fourth row is why this post exists. Everywhere else on our site, a "no" ends the same way: this is on the roadmap, it is commissionable, here are the terms — a written specification, a timeline and a price agreed before anything starts. We would say that about the first three rows without hesitation. We will not say it about the fourth, because finishing the engineering behind a certification submission is the beginning of an application rather than the end of one, and a vendor who puts a date on that is describing something they do not control.
It follows that being close is not the same as being nearly there, and we would rather write that sentence about ourselves than let the three encouraging rows in the table do quiet work they have not earned.
What to do with this if you are buying software
The practical move is small. Before you build a feature matrix for any market you are not from, find out which kind of rule that market has — and if it has the second kind, run the register check on every vendor on your list before you compare a single feature. It takes two minutes per vendor, it is the only question on your list that a demonstration cannot answer, and it is the only one that can invalidate the whole exercise retrospectively.
Four questions, and the first one is not asked of the vendor
Does this market regulate the document, the software, or both?
What a good answer sounds like
A clear answer from your accountant or a local adviser, before the shortlist is drawn. In some markets the answer is a public register you can search yourself.
What a bad answer is telling you
If nobody on the project can answer this, the evaluation is being run on an assumption. It is the cheapest assumption to check and the most expensive to get wrong.
Are you listed on this market's register of approved software, and under what name?
What a good answer sounds like
A name and a number you can verify yourself in two minutes, or a straight no.
What a bad answer is telling you
If the answer is "we are fully compliant", that is a claim about capability answering a question about accreditation. Ask again, and ask for the entry.
If you are not listed, what would it take, and who decides the outcome?
What a good answer sounds like
A description of the engineering, and an explicit statement that the decision belongs to the authority. Ours is exactly that.
What a bad answer is telling you
A delivery date for certification is the answer to watch for. It is a promise about a third party's decision, and the vendor making it either does not understand the requirement or is hoping you do not.
If our documents must be issued elsewhere, what is left for this system to do?
What a good answer sounds like
A frank division of labour. For most operational software the answer is most of the product, and the honest vendor will say so rather than fight for the module they cannot have.
What a bad answer is telling you
If the answer is that everything falls apart without invoicing, you are being sold an accounting package with an operations module rather than the reverse. Worth knowing either way.
What we would build, and where we stop on purpose
The three engineering rows, in the order they earn their keep, and the first two are not Portuguese work at all: put both tax identification numbers and the customer's address on the printed document, since all three are stored today and none of them prints; make the document counter genuinely private to each organization; then a ledger export carrying documents, lines, customers, products and tax codes rather than seven header columns. Those improve every European market in the product. The Portuguese-specific engineering behind a certification submission is a larger and separate piece and we would scope and price it like any other build. What we will not do is tell you when the certificate arrives, because that is not ours to say.
What AWRA OpsHub does today
- A locked, per-organization, per-year document counter behind every sales document — the structure a registered series needs, minus the registration.
- A tax authority's machine-readable code rendered on the invoice, in vector, from a stored payload, with a receipt number, a receipt signature and a filing timestamp beside it. Kenyan, live, and evidence that this shape of work is ordinary for us rather than aspirational.
- Refusal to delete an issued invoice. Corrections run through cancellation or a credit note.
- The operational product in full — stock across sites with acknowledged transfers, batch traceability, quality holds, landed costs, procurement with three-way matching, an asset register with named custodians, projects, helpdesk and personnel records — none of which is touched by any of this.
What it does not do
- A certified invoicing program, and no entry on any Portuguese register. First on this list because it is the only item on our site that is not work we can be commissioned to complete.
- Series registration and an authority-supplied code, so nothing our documents print can be a unique document code.
- A ledger export in any prescribed schema. Our invoice export is seven header columns with no document lines, no rates and no tax codes.
- Any communication of billing records to a Portuguese authority. There is none, in any tense.
Not ours, by choice
- We will not date the certification. We would scope and price the engineering on the usual terms. The certificate is theirs to certify, and a vendor implying otherwise is selling you a risk they have not priced.
- We will not tell you whether the rule catches your business. The conditions turn on where you are established, what you turned over and how you keep your accounts. Naming them is useful; applying them to your company is a determination your accountant makes and signs.
- We will not be your filing agent, here or anywhere. Even with every integration built, submitting on your behalf and standing behind the contents is not work we would take on.
The three engineering items are well specified and we would quote them today, and two of the three are not Portuguese work at all — they are things every European market in the product needs and would get. The certification-specific engineering we would scope as a build and price honestly, with the standing caveat that completing it starts an application rather than finishes one. The precedent that we finish market-specific work of this kind is Kenya: a live authority integration with a machine-readable code, a receipt number and a signature on the document, and a maintained statutory payroll engine, both ours and both still maintained. A written specification, a timeline and a price agreed before anything starts, and no dates on a public page.
Worth stating rather than leaving to be inferred: none of this touches a business whose invoicing already lives in a certified package. If that is you, the rules in this post are somebody else's problem and what you are evaluating us for is stock, procurement, projects, assets, maintenance, helpdesk and people — where none of these questions apply and the answers are ordinary.
What is not built for Portugal today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Portugal. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If the engineering behind a certification submission, scoped honestly, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Three builds we would quote, and one thing we would not pretend to schedule
Start with the work that is specified and portable. Put both tax identification numbers and the customer's address on the printed document — all three are stored today and none of them prints. Make the document counter genuinely private to each organization, because for sales invoices, credit notes, purchase orders and point-of-sale documents it is currently reconciled against a number unique across the whole platform, so a sequence can skip for reasons that have nothing to do with the business reading it; that one we would treat as a correction rather than a feature. Then a ledger export that carries documents, lines, customers, products and tax codes, instead of the seven header columns the invoice export emits today. All three improve every European market in the product rather than only this one. The Portuguese-specific engineering is a separate and larger piece — document series registered with the authority in advance, the unique document code that comes back, the authority's own QR payload rendered on the document, the prescribed export schema, and the record-integrity properties the requirements test for — and we would scope and price it like any other build. What we would not do is put a date on the certification itself. That is granted by the Portuguese tax authority against its own requirements, and finishing the engineering is the beginning of an application rather than the end of one. Every other paragraph in this section of the site ends with terms we would agree with you; this one ends by saying which part is not ours to agree.
Banks and payments
SEPA credit transfers and direct debits, Multibanco references and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents that authorised it rather than being re-keyed from a bank screen.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Portuguese payroll engine with statutory withholding and social security contributions computed on live employee records, and the monthly schedules produced in the layout the filing body expects. None of it exists today; labour cost attribution to projects and cost centres does.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe one-line version
Before you ask what a system can do in a market, find out whether that market regulates what the system is. The first question has a price and a date. The second has a register, and no amount of engineering enthusiasm changes what is written in it.
The Portuguese version of this, in full
Our country page sets out all four obligations against our own code, including the three where we are closer than we expected and the one where being close does not count. It also says plainly what is left — which, on this product, is most of it.
Read the Portugal page