The Chain That Reports Itself Upward
Japan asks the main contractor on a large enough job to keep a ledger of everyone working under it — each subcontractor's name, what they are doing, and for how long — on the site itself. It then does something most registers do not: it makes each tier responsible for telling the tier above who <em>it</em> engaged. The register is not assembled by the person who keeps it. It is fed upward, by duty, from the bottom.
Two documents, one of them a diagram
The provision is Article 24-7 in the translation we read, and it produces two artefacts rather than one. The first is a work ledger — 施工体制台帳 — which the Act says must state the trade name or name of the subcontractor, the content of the construction work with regard to that subcontractor, the period of the work, and other matters an Order of the Ministry of Land, Infrastructure, Transport and Tourism specifies. It must be kept <em>in each construction site</em>.
The second is a work plan — 施工体系図 — showing the distribution of work among each subcontractor, and it must be placed in an easily visible location at the construction site. That is a diagram, on a board, where people can see it. Not a report, not an export, not a page in a system: a picture of who is doing what, displayed where the work is happening.
Three things about this source
The Ministry of Justice's database records this Act's translated version as Act No. 28 of 2008 and states that its translations are not official texts. The Act has been amended since, including a renumbering — the provision quoted here as Article 24-7 is commonly cited today as Article 24-8, and the article number above is the one in the version we read. And the two things that would matter most operationally are both delegated: the threshold is an amount specified by Cabinet Order, and the full field list of both documents is in a Ministry Order. We read neither, so no figure and no field list beyond the three items the Act itself names appears in this post.
The mechanism worth copying
Paragraph (2) is the interesting one. Where a subcontractor on that work has subcontracted the work on to another person operating a construction business, the subcontractor must notify the main contractor of that other person's name, the content of the work they have undertaken, the period of construction, and other prescribed matters. So the obligation to keep the register sits at the top and the obligation to populate it sits at every level below.
That is a different design from the one most procurement systems assume. A supply-chain register normally works by the buyer asking, chasing, and eventually giving up — which is why the honest answer to "who is three tiers down your supply chain" is usually nobody knows. Here the answer is a duty running the other way, and the register is a place for the answers to land rather than a questionnaire.
Paragraph (3) then adds an audience. On request by the orderer — the client who commissioned the work — the ledger must be made available for the orderer's inspection. Not a regulator: the customer. Which makes the register a document three different parties have an interest in, maintained by contributions from parties who are not the one keeping it.
The party who must keep the register is not the party who must fill it in. That single inversion is what makes a multi-tier chain knowable at all.
What we have that fits, and what does not
The pieces here are better than you might expect, because one of them was built for a different reason. A purchase order in this product can name a project — the column is there and it is indexed per organization — so the set of suppliers engaged on a job is selectable wherever the order was raised against the project. That gives you the first tier, cleanly, from data you already keep.
The second tier is where it stops, and the reason is a schema fact we established from a different angle in <a href="/blog/the-supplier-behind-your-supplier">The Supplier Behind Your Supplier</a>: a vendor in this product has relations to the organization, to its own portal users, and to the RFQs, quotations and purchase orders it is party to — and no relation to another vendor. There is nowhere for "this supplier engaged that supplier" to be recorded, whether the fact arrives by duty or by questionnaire.
What we do have, and what makes the upward-notification model unusually reachable, is a working channel for a supplier to submit facts about its own work. A supplier with a portal login can see the RFQs it has been invited to and the purchase orders it holds, submit a quotation, acknowledge a purchase order, close one, update its shipping status, and upload an invoice against it. That is not a read-only window; it is a place where a counterparty already writes into your records under its own identity.
What Article 24-7 needs, against what exists
| The requirement | Held today | Per project | Submittable by the party who knows |
|---|---|---|---|
| The first tier of subcontractors | Yes | Yes | No |
| What each first-tier supplier is doing | Partly — configurable by you | Yes | Partly — configurable by you |
| The period of each supplier's work | Partly — configurable by you | Partly — configurable by you | No |
| The second tier and below | No | No | No |
| A channel for a supplier to submit facts | Yes | Partly — configurable by you | Yes |
| A diagram of who is doing what | No | No | No |
| Inspection by the client on request | No | No | No |
| A document kept at a physical site | No | No | No |
Built and maintained Configurable by you, not maintained by us Not built
Row five is the one that changes the shape of the problem. The channel exists and suppliers already use it to write into your records — a quotation, an acknowledgement, a shipping status, an invoice. Adding "and the party you have engaged for part of this work" to what a supplier can submit is a form on a screen that already exists, not a new relationship with your supply base. Row two and row three are partials because a purchase order describes goods and services and dates in its own terms rather than as a scope-and-period statement about a project.
The last two rows are the ones software genuinely cannot close. A document that must be available for the client's inspection is a disclosure to somebody outside your workspace, and we have no time-limited external link to a stored document — a gap we set out in <a href="/blog/a-form-somebody-else-owns">A Form Somebody Else Owns</a>. And a document whose required location is a wall at a construction site is not a software requirement at all. What software can do is produce the thing that gets printed and pinned up, and know when it last changed.
Suppliers engaged on a named project
A purchase order can carry a project reference, indexed per organization, so the first tier on a job is a query.
A supplier portal a counterparty writes into
A supplier can submit a quotation, acknowledge and close a purchase order, update its shipping status and upload an invoice, under its own login.
Onboarding a party who is not yet a supplier
A public prequalification flow takes an application with documents and turns an approved applicant into a supplier record.
Named, ordered checkpoints on a project
Milestones carry a name, a due date, a status and an order, and tasks group underneath them.
A document with a checksum and an access log
The vault holds a file with its classification, a SHA-256 checksum, a relation to any record and a log of every read.
A supplier engaged by another supplier
A vendor relates to the organization and to its own documents; a relation from one vendor to another would be the record a tiered chain needs.
A scope and a period per supplier per project
A purchase order describes what was bought; what a party is doing on a job, and between which dates, would be a statement about the project rather than about an order.
A diagram of the distribution of work
The register as a picture rather than a list, produced from the chain and printable for a site board.
What AWRA OpsHub does today
- A purchase order that can name its project, indexed per organization, so the suppliers engaged on a job are selectable.
- A supplier portal with write access, where a counterparty submits a quotation, acknowledges and closes a purchase order, updates shipping status and uploads an invoice under its own login.
- A public prequalification flow, taking an application with supporting documents and turning an approved applicant into a supplier record.
- Named, ordered milestones on a project, with due dates and statuses, and tasks grouped underneath them.
- A document vault with a checksum, a classification and an access log, related to whichever record a document concerns.
- A full audit trail on the records involved, carrying the actor, the moment and the values that changed.
- Custom fields on vendors, purchase orders and projects, so a scope, a period or a parent supplier can be recorded as a value today.
More we can add to your workspace
- A relation from one supplier to another, which is the single record a tiered chain is built from.
- A scope and a period per supplier per project, stated about the job rather than inferred from what a purchase order bought.
- A submission form for the tier below, so a supplier can name the party it engaged, through the portal it already writes into.
- A register assembled from those submissions, per project, with the date each entry arrived and who submitted it.
- A diagram of the distribution of work, produced from the register and printable for a site board.
- A time-limited, logged link for a client to inspect a document, so an inspection right can be honoured without an account.
- A record of when the displayed version was last produced, which is what makes a physical document on a wall auditable.
Where we point you to a specialist
- We will not tell you whether you are a special construction business operator, or whether your subcontracting total crosses the threshold. The duty falls on an operator holding a particular kind of licence who took the work directly from the orderer, and the trigger is an amount set by Cabinet Order which we did not read. Both are questions for a Japanese construction-law adviser, and the first one decides whether any of this applies to you.
- We will not reproduce the field list of either document. The Act names three items for the ledger and then delegates the rest to a Ministry Order, and the diagram is delegated entirely. If we build register support for you, the fields come from the current Order with the date we took them recorded, so a stale version is visible rather than assumed.
- We hold a position on who should enter a fact, and this Act happens to agree with it: the party who knows. A register maintained by the top of a chain asking questions downward will always be incomplete, because the people with the answers have no obligation and no channel. We would rather extend the portal a supplier already writes into than build a questionnaire, and we would attribute every entry to the party that submitted it and the day it arrived.
The first item is one nullable relation and it is what everything else needs. The third is a form on a screen suppliers already use, which is why this obligation is more reachable in this product than a general supply-chain mapping exercise would be — the identity, the login and the audit trail are all in place. The second and fourth follow from those two and are mostly reporting. The fifth is a rendering job and pleasant work. The sixth is the same external-access question we have flagged elsewhere and worth solving once for several obligations. The seventh is a timestamp.
What we can build for Japan on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Japan, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If rounding at the currency's own precision, consumption tax subtotalled per rate, a registration number field, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have 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.
The arithmetic before the document
Japan is the market where our own arithmetic is the first thing to fix rather than a field we are missing. The invoice, quotation and point-of-sale paths round money to two decimal places as a hardcoded literal, and the yen has no minor unit — so a three-line invoice at the standard rate produces a consumption tax of ¥423.4, an amount that cannot be invoiced or paid. We already hold the correct number of places for every currency as reference data; that code simply does not read it. On top of that sits the requirement that gives the fix its shape: a qualified invoice must show consumption tax categorized by tax rate, and the rounding is permitted once per rate rather than once per document. Our invoice carries a single tax figure with the rate on the line, so the per-rate subtotal in between does not exist — and it is the same piece of work as the rounding, which is why we would build them together rather than in sequence. Separately and smaller: a tax registration number on the organization, on customers and on suppliers, since no column for one exists anywhere today.
Banks, payments and a currency with no decimals
Bank statement feeds and local payment rails wired into the Payments Register, with documents raised and reported in yen at the precision the yen actually has. What we will not do is treat our copy of the public register of qualified invoice issuers as authoritative for your credit entitlement — we will hold the number you recorded and the date you checked it, and leave the checking where it belongs.
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 Japanese payroll engine with income tax withholding, the standard-remuneration social insurance grades and the year-end adjustment, computed on live employee records rather than rebuilt in a spreadsheet each December.
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 integratedFour questions for a system that will map a chain
Who is working on this project?
What you will probably hear
Everyone with a purchase order against it.
How to read it
That is the first tier and it is a good answer as far as it goes. Ask what happens when one of those suppliers engages somebody else — in most systems, ours included, there is nowhere for that fact to live, so the register stops at the depth your own orders reach.
Can a supplier tell us something we did not ask for?
What you will probably hear
They can email their contact.
How to read it
Then the fact arrives as prose and lands in an inbox. Ask whether the supplier portal can take a structured submission, because a channel a counterparty already logs into and writes to is the difference between a register that fills itself and a chase list.
Can our client see this register?
What you will probably hear
We would send them a PDF.
How to read it
Which satisfies the request and records nothing. Ask whether an external party can be given one document, for a bounded time, with the access logged — because an inspection right is one you will later need to show you honoured.
How do we produce the version that goes on the site board?
What you will probably hear
Export it and print it.
How to read it
Fine, and ask what records the fact that you did. A document whose legal requirement is to be displayed needs a produced-on date and a way to tell whether the register has moved since — otherwise the board is showing a truth from three weeks ago and nothing knows.
Our take
This is the most reachable multi-tier obligation we have looked at, and the reason is the supplier portal. The hard part of mapping a chain is normally getting the people below you to tell you anything; here the law already obliges them to, and we already run a channel they log into and write records through. What is missing is one relation — a supplier engaged by a supplier — and a form. Until those exist, the first tier is a query against purchase orders that name the project, the tiers below it are a spreadsheet somebody maintains by hand, and the diagram is drawn in a drawing program. If you build in Japan at any scale, this is a small and unusually well-specified piece of work, and the register it produces would be useful in every jurisdiction that asks about your supply chain.
Tell us how deep you need to see
Most supply-chain visibility projects fail on the same thing: the party with the information has no reason and no route to give it to you. Where a duty exists, the route is the whole build. We looked at the reporting side of supply-chain depth in <a href="/blog/the-supplier-behind-your-supplier">The Supplier Behind Your Supplier</a>, and at the two documents an RFQ can reach its quotations through in <a href="/blog/two-relations-and-one-is-always-empty">Two Relations, and One Is Always Empty</a>.
Talk to us about your workspace