Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Japan · East Asia
Most market pages in this corpus argue about what a system does with a number. Japan is the first that argues about the number. Under the qualified invoice system the consumption tax on an invoice may be rounded once for each tax rate — not once per line, and not once per document — and because the yen has no minor unit, that rule decides the figure rather than dressing it. Ours rounds once per document to two decimal places, in a currency that has none. Below: that arithmetic reproduced with real amounts, the three entries a qualified invoice requires that our schema has nowhere to put, and one finding that has nothing to do with tax at all.
What the document has to carry
A qualified invoice is the older classified invoice with three things added to it: the issuer's registration number, the applicable tax rate, and the consumption tax categorized by tax rate. A buyer keeps that document because keeping it is what entitles them to credit the tax. Of the three additions, we hold one.
The registration number
No field for itWhat is required
An invoice may only be issued as a qualified invoice by a business registered with the district director, and the number it is issued under goes on the document. The buyer's entitlement to credit the tax rests on holding an invoice that carries one.
What we hold
No column exists. Not on vendors, not on customers, not on the organization itself — we checked the schema rather than the screens. This is not a field we render badly; it is a field we do not have.
The applicable tax rate
HeldWhat is required
The rate each line is charged at must appear on the document.
What we hold
Held, and held well. The rate is stored on the invoice line as a figure at the moment the document is raised, so it never drifts when a reference table is edited later. This is the one of the three we get right, and it is the same property that protects a Liberian invoice through a rate change.
The consumption tax, categorized by tax rate
No field for itWhat is required
The tax must be shown broken out per rate band. Japan runs 10% and 8% at the same time — the 8% covers food and some subscriptions — so an invoice carrying both is the ordinary case rather than an edge case.
What we hold
The invoice carries a single tax figure. The rate lives on the line and the tax lives on the header as one scalar, so we can tell you what each line was charged at and what the document totals, and we cannot produce the one number in between. This is also what blocks the rounding rule: you cannot round once per rate without a per-rate subtotal to round.
The middle row is worth reading as evidence rather than as consolation. Storing the rate on the line instead of looking it up is the sort of decision that is invisible until a rate moves or an auditor asks, and it was made correctly. The two empty rows are absent fields, which is a different class of work from a wrong behaviour — and a more honest thing to be told before you buy than after.
And one finding that is not about tax at all
Nothing in this section is about tax. Japan closes nationally three times a year — the New Year period, Golden Week in late April and early May, and Obon in August — and a supply plan is built around those far more than around a filing date. The holidays themselves are where we found something.
A public holiday in our system is a date with a "recurring" flag on it. When the flag is set we generate the same month and the same day in every subsequent year, which is correct for the first of January and correct for most countries most of the time.
Japan has sixteen national holidays and six of them do not work that way. Four sit on the *n*th Monday of a month under the law that moved them there to make three-day weekends — Coming of Age Day on the second Monday of January, Marine Day on the third Monday of July, Respect for the Aged Day on the third Monday of September, and Sports Day on the second Monday of October. Marked as recurring from the date they fall on this year, each one lands on a Tuesday next year and a Wednesday the year after.
The other two are stranger and better. Vernal Equinox Day and Autumnal Equinox Day are set by astronomical calculation, and the dates are not formally fixed until the observatory publishes its almanac in February of the preceding year. They are public holidays whose date is genuinely not knowable far in advance, so there is no rule to encode — only an annual entry somebody has to make.
So a Japanese organization setting up its calendar has six entries that must be corrected by hand every year, and nothing tells them. The first year is right, which is the problem: a wrong recurring holiday does not fail, it silently marks a working Tuesday as closed and a national holiday as open, and it does that inside leave balances, availability and anything scheduled around a working day.
Recorded here rather than in a support note because it is the honest version of what "we support public holidays" means on this product today. An *n*th-weekday recurrence rule is a small, well-understood piece of work and it is on the commissionable list below. The equinoxes are not a rule and never will be — that one is a yearly entry in anybody's system, including the ones that cost more than ours.
What this costs you in practice
The yen has no subunit, so any consumption tax figure carrying a decimal is not a rounding preference — it is an amount that cannot be invoiced, paid or filed. It will not stop a document from being produced. It will be noticed by whoever reconciles it.
The 8% band on food and some subscriptions means a single invoice routinely carries two rates, and the document is required to show the tax for each. A system that holds one tax figure per invoice cannot produce that line, however correct its total is.
Your right to credit the tax on a purchase depends on the invoice you keep being a qualified one, issued under a registration number. If there is nowhere in your system to record that number, the check that matters is happening somewhere else.
Six of Japan's sixteen national holidays are not on a fixed date. A recurring entry made this year is correct this year and quietly wrong from next, which is worse than being obviously wrong.
Running the operation, not filing for it
Japan is a market where the operational constraints are calendar-shaped rather than infrastructure-shaped. The roads work, the network works, and the things that bite are the dates.
Inventory
Three national shutdowns, planned as lead time rather than as absence
New Year, Golden Week and Obon each stop receiving and dispatch for the better part of a week, and they are the same weeks for your suppliers. Replenishment runs off consumption against a lead time you set per location, so the closure is planned as a longer lead time into the period rather than discovered as a week of stockouts after it.
HR
A working calendar you set, with six entries you have to watch
The working week and the holiday list are the organization's own rather than ours, which is the right default in a market whose holidays we do not encode. Read the calendar section above before you rely on the recurring flag — four of Japan's holidays move to a different date each year and two are announced annually.
Procurement
Supplier records that hold what you need to prove later
Approvals, documents and correspondence sit against the supplier rather than in somebody's mailbox, which matters more in a market where the question asked two years later is usually about the counterparty rather than the amount. What they will not hold today is a registration number, which is the finding above and not a detail.
Assets
Inspection intervals against the asset, not against a spreadsheet
Equipment that has to be checked on an interval carries the interval on its own record, with the history of what was done and by whom. This is market-neutral and we say so rather than dressing it as a Japanese feature — it is here because it is the thing most operators ask about third.
Four items rather than six, deliberately. The rest of what we do in Japan is the same as what we do everywhere, and six cards padded to look local is the exact pattern this page is trying not to be.
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
Three of those five are one piece of work rather than three, and it is the piece this page is about: give a document a tax subtotal per rate band, round each one at the currency's own precision by the method the issuer picks, and the rounding rule, the per-rate figure and the yen's missing decimal all resolve together. The registration number and the nth-weekday recurrence are smaller and independent. All of it is 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.
The arithmetic finding is ours, it is published here with the figure, and it is not conditional on anybody buying anything. If you would rather take it to a system that already rounds the way Japan requires, that is a reasonable conclusion and this page exists so you can reach it before an implementation rather than during one.
How this starts
In whatever system you are evaluating, including this one. Three lines, standard rate, ordinary shelf prices. Then look at the tax figure and ask whether it is an amount of money. This takes two minutes and it is the single most informative thing you can do to an accounting system in this market.
Then look for the tax shown for each rate. The qualified invoice requires that breakdown, and it is the requirement most likely to be answered with a total and a shrug. If the system can only show you one figure, it is not producing a compliant document however right that figure is.
It is the second Monday of January. Whatever date you enter it on, check what the system thinks it is twelve months later. The answer tells you whether its recurrence is a rule or a repeated date, and that distinction reaches leave, availability and anything scheduled on a working day.
Read before you shortlist
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.
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.
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.
The questions a Japanese finance team actually asks
No, and the reason is specific rather than general. Of the three entries the qualified invoice system adds to an invoice, we hold one properly — the applicable tax rate, stored on the line. We cannot render a registration number, because no field for one exists anywhere in the schema. And we cannot show the consumption tax categorized by tax rate, because an invoice carries a single tax figure. On the roadmap and commissionable now — the per-rate subtotal is the same piece of work as the rounding fix described above, so the two ship together, and the registration number is a smaller independent change. A written specification, a timeline and a price, with Kenya's eTIMS transmission as the evidence that we build this rather than talk about it. No date on a public page.
It is real and it is ordinary. It came from running our own invoice controller's arithmetic on three lines at the standard rate with prices of ¥1,980, ¥333 and ¥1,255. The only thing that makes the fraction appear is that the prices are not multiples of ten, which is true of most prices. You can reproduce it in a trial account in about two minutes, and step one above tells you how.
Two halves, and they have different answers. The arithmetic is not wrong, it is unrounded — we compute line tax exactly and round the document once, so the figure is accurate to more places than the currency has rather than incorrect. Your total will not drift from what the maths says. What is wrong is that the result is not expressible: a tax of ¥423.4 is not an amount that can be invoiced or paid, and Japan's rule is that the rounding happens once per tax rate rather than once per document. So the exposure is a document your counterparty or your filing cannot accept, not a balance that silently disagrees with itself.
Less, and not nothing. On a single-rate invoice a per-rate subtotal and a document total are the same number, so the missing breakdown costs you nothing today. It becomes a problem the moment one line of food or a qualifying subscription appears on a customer invoice, and it is worth knowing that the constraint is one line away rather than absent. The rounding defect, on the other hand, applies to you now — it is a property of the currency, not of how many rates you use.
No, and this one is a boundary rather than a backlog. We will hold a supplier's registration number once the field exists, and that is straightforward work we would commission. We will not check that number against the public register and report it to you as verified, because your entitlement to credit the tax on that purchase would then be resting on our copy of somebody else's data being current. That is a dependency we would rather you did not have on us. Look the number up at source, record what you found and when, and let the system hold the record rather than the judgement.
Not today. Two halves, and they have different answers. A boundary rather than a backlog: we will not bundle a Japanese interface into a standard implementation, and that position protects you rather than us. Translating an operational system is every screen, every notification, every error and then the maintenance of all three, and a half-translated system is worse than an English one — it teaches people to distrust the parts they can read, which is how a rollout dies quietly in month three rather than loudly in week one. On the roadmap and commissionable now: as a project of its own, with a written specification, a timeline and a price, scoped to the screens your people actually work in rather than to the whole product. If neither of those is what you want to hear, choosing a system that already ships in Japanese is a perfectly good answer and we would rather you reached it here.
Yes, and this is the part of the product that is genuinely strong rather than the part we are apologising for. Multiple organizations with their own base currencies, their own tax rates and their own working calendars run side by side, and reporting can be scoped to one or consolidated across several. The caveat is the honest one: figures in different currencies are shown as themselves rather than converted and added together, which is deliberate — a single total across currencies is a number somebody will act on and no exchange rate makes it true.
The first year is correct and every year after it is quietly wrong for six days. A recurring holiday repeats on the same month and day, so the four holidays fixed to the *n*th Monday of a month drift by one weekday a year, and the two equinox holidays cannot be encoded as a rule at all because their dates are announced annually. Nothing fails and no error appears — a working Tuesday is marked closed and a national holiday is marked open, inside leave balances and availability. Until the recurrence rule is built, the answer is to enter Japan's holidays as dated one-offs each year rather than as recurring entries, which is tedious and correct.
Raise one invoice with awkward prices, put two rates on one document, and see what comes out — here, or anywhere else you are looking. If our answer on rounding is not good enough for your next filing period, that is a legitimate conclusion and better reached now. If the operations half is what you actually need, most of this page is not your problem.