Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Taiwan · East Asia
The Act is named for two regimes and it means it. Most Taiwanese businesses are on the value-added one: tax paid to a supplier is deducted from tax charged to a customer, so it is a receivable. Financial businesses sit under a different article on the non-value-added one, taxed on gross receipts with no input credit at all, so the same payment is simply a cost. Nothing about that distinction is a percentage. It decides which side of the ledger an amount belongs on — and our system records the amount without recording which.
Two regimes, one Act
A retailer and a bank on the same street each pay tax to a supplier. Identical amount, identical invoice, entirely different accounting fact — and the difference comes from which article of one statute they fall under.
This is the Eritrea and San Marino problem — a tax that is not a value added tax, so what you pay a supplier is a cost rather than a receivable — except that here both regimes exist inside one country at the same time, under one Act, decided by what kind of business you are. It is not a national fact and cannot be held as one.
Worth naming the rate question just to dismiss it: Taiwan's operative business tax rate is 5%, and the Act itself does not contain that figure — article 10 sets a band and leaves the number to the executive. Interesting, and beside the point. A page about mechanism should not be read as a page about rates, which is why the article 11 sector figures are deliberately not printed here.
Our side of it
This part is about our system rather than about Taiwan, and it is stated narrowly on purpose — a broader version of it has been written in this corpus before and was wrong.
An expense in our system carries a tax amount. That is real: if you paid tax on a purchase, the figure can be recorded against the expense and it will be there afterwards. A purchase order carries no tax at all, which is a separate and smaller gap, because a purchase order is a commitment rather than a transaction.
What the expense does not carry is the **rate** that produced the amount, or any flag saying whether that amount is recoverable. There is no column for "this is a receivable" and no column for "this is a cost", because until now the distinction has never had to be made — in the great majority of markets and businesses, tax paid on a purchase is recoverable and the question does not arise.
In Taiwan it arises inside a single country. A retailer and a bank record the same expense with the same tax amount, and one of those amounts is money coming back while the other is money gone. Our records are identical. The distinction lives entirely in whoever does the accounts.
So the honest statement is not that we ignore purchase-side tax — we hold the amount. It is that we hold a number whose meaning we do not hold, and in a market running two mechanisms at once that is the difference between a bookkeeping record and a set of accounts.
What this costs you in practice
Tax paid on a purchase is recorded as an amount and nothing says whether it comes back. For most businesses that is harmless because the answer is always the same. In a country running two mechanisms, it is the whole question.
A financial business whose system treats input tax as recoverable is carrying a balance that no filing will ever recover. It reconciles perfectly against itself and against nothing else.
Our country profile records a single mechanism for Taiwan. That is right for most Taiwanese businesses and wrong for a whole sector, and the profile has no way to say "it depends what you do".
Taiwan's Act sets a band and leaves the operative figure to the executive, so a reader who goes to the primary source finds no number at all. Worth knowing before somebody "corrects" a rate against the legislation.
Running the operation, not filing for it
The tax argument above affects a specific set of businesses. The operational questions here are the ones a dense manufacturing and electronics supply base produces, and they affect everybody.
Inventory
Traceability down to the batch that shipped
In an electronics supply chain the question after a fault is which units carried the affected part, and the answer has to survive a year of turnover. Lot and serial tracking are held against movements rather than reconstructed from paperwork, so the trace runs both directions from any point.
Procurement
Receiving matched against the order, with tolerances
Short shipments and substitutions are ordinary in a components supply base, and the useful record is what arrived versus what was ordered, captured at the door with the discrepancy attached rather than argued about later from an inbox.
Inventory
Quality holds that actually stop a shipment
Stock placed on hold is not merely flagged — it is not available to pick, so a hold is a control rather than a note somebody may read. That distinction matters most where the cost of shipping a suspect batch is a recall rather than a return.
Assets
Inspection intervals held on the equipment
What has to be checked, how often, what was found last time and by whom, carried on the asset record rather than in a maintenance spreadsheet nobody owns.
Four items, and three of them are true of any manufacturing market. They are listed because they are what Taiwanese buyers ask about once the tax conversation is over, not because we found something uniquely Taiwanese about receiving goods.
Scope, in three parts rather than two
Three columns, because "no" means two entirely different things and one list hides which is which. The middle column is work that has not been done and has a price. The right-hand column is work we would decline from a paying customer — and it is the one worth demanding from every other vendor you talk to, because a page without it has not told you where its edges are.
Running in the product today
Not built yet — and commissionable
What we would decline, and would rather say now
The first two rows of the middle column are one piece of work and it is not large: give purchase-side tax a rate and a recoverability classification, and the Taiwanese distinction becomes something you record rather than something your accountant carries in their head. The per-business mechanism is the larger change and depends on it. All commissionable now with a written specification, a timeline and a price — Kenya's eTIMS transmission and our payroll engine are the evidence that we build this way rather than describe it.
If you are on the value-added regime, which most Taiwanese businesses are, the gap above costs you a checkable rate rather than a wrong ledger, and the operational half of this page is the part that matters to you. If you are a financial business under article 11, read the middle column carefully before you go further, because the mismatch is in the accounts rather than on the invoice.
How this starts
In any system you are evaluating. Then ask what in that record says whether the tax comes back. If the answer is "the account it was posted to", the classification is a convention rather than data — which works until somebody posts it differently.
A one-line question with a structural answer. Most systems answer "country", because most countries only have one. Taiwan is where that assumption produces two businesses with identical records and opposite accounts.
Nothing to do with tax, and the thing most likely to matter to you in month eighteen. Pick a delivery, find which incoming batches it consumed, and see whether the answer takes a query or an afternoon.
Read before you shortlist
Taiwan runs two tax mechanisms inside one statute. Most businesses deduct what they paid a supplier; financial businesses cannot. The same payment is a receivable for one and a cost for the other — and nothing about that is a percentage.
We record how much tax was paid on a purchase and not what it means. That gap has a general shape — a stored value whose interpretation lives outside the data — and once you see it you find it in landed costs, quantities and dates.
Ask whether tax mechanism is a property of the country or of your business — then ask whether the vendor would guess it from your industry. The right answer to the second is no.
Ask where rounding happens, and ask to see the tax for one rate on a two-rate invoice. Five tests you can run yourself in fifteen minutes — with our own answers beside each, including the one that cannot be paid.
Our public holidays repeat on the same date every year. Six of Japan's sixteen are not on a date at all — four are the nth Monday of a month and two are announced annually. The first year is correct, which is the problem.
Japan does not only say what your invoice must show. It says how the consumption tax may be rounded — once per rate band — and the yen has no minor unit. Our own system produces a tax figure of ¥423.4.
What a Taiwanese finance team asks after the rate question
For charging, yes — the rate is configurable and stored on each invoice line when a document is raised, so what you charge is right and stays right. For the purchase side, partly, and the gap is specific rather than general: we record the tax amount on an expense, and we do not record whether that amount is recoverable. Under the value-added regime it is; under article 11 it is not; and our record looks the same either way. On the roadmap and commissionable now — a recoverability classification and the rate alongside the amount, as a written specification with a timeline and a price. Kenya's eTIMS transmission is the evidence we build this way rather than talk about it.
For the accounting half, probably, and we would rather say so at this stage than at implementation. Under article 11 the tax you pay suppliers is a cost rather than a receivable, and our expense record cannot express that — so the figure would need to be classified outside the system or handled by convention in how it is posted. Conventions work until somebody new posts one differently. The operational half of the product does not care what regime you are on and is unaffected. If the accounting distinction is the reason you are buying, we are the wrong answer today.
Because article 10 sets a band rather than a figure — no less than 5% and no more than 10% — and leaves the operative rate to the executive. The result has been 5% since the tax was reformed in 1988, so the band has never actually been used to move it. Worth knowing for a practical reason: anybody "correcting" a Taiwanese rate by going to the primary source will find no number there, and may conclude the reference is wrong when it is not.
We could and we will not, and this is a boundary rather than a backlog. A rule guessing from a business category would be right most of the time, and every failure would be silent, would land in the accounts rather than on a document, and would be discovered by an auditor rather than by an error. That is the worst possible shape for a heuristic. The mechanism should be recorded because somebody determined it, with a date on when they did — which is what the commissionable work above actually builds.
No — a purchase order carries no tax in our system at all. It is worth separating from the finding above, because it is smaller and more defensible: a purchase order is a commitment rather than a transaction, and tax becomes real when the expense does. It is on the commissionable list as the natural companion to giving purchase-side tax a rate and a classification, and we would build the three together rather than separately.
Not today. Two halves, and they have different answers. A boundary rather than a backlog: we will not fold a translation into a standard implementation, because a half-translated operational system is worse than an English one — it teaches people to distrust the screens they can read, and rollouts die of that quietly. On the roadmap and commissionable now: as its own project with a specification and a price, scoped to the screens your people actually work in. If a Traditional Chinese interface is required on day one, a system that already ships in it is a perfectly reasonable answer.
Traceability and the supply base, which is what most Taiwanese operations actually run on. Lot and serial history held on movements so a trace runs both ways from any point, quality holds that make stock genuinely unavailable rather than merely flagged, receiving matched against orders with the discrepancy captured at the door, and inspection intervals carried on the equipment. None of it is affected by the tax argument on this page, and for a manufacturer on the value-added regime it is most of the reason to talk to us.
It is one line, it has a structural answer, and in Taiwan it separates a bookkeeping record from a set of accounts. If our answer is disqualifying for a financial business, that is a fair conclusion and better reached here than in month two.