CLIENT: Hoshizora Cloud K.K.🇯🇵Japan

Tsumugi - Subscription Billing with Qualified Invoices and Furikomi Matching

Subscription Billing for a Japanese B2B SaaS Company

Designed and built a clickable billing platform for a Tokyo SaaS company that sells shift scheduling and attendance software to Japanese businesses: invoice runs by each customer's closing date, qualified invoices with tax rounded once per rate, bank transfer matching on half-width katakana payer names, and dunning by payment method.

Scope of Work
Product design, UI build and clickable demo
Industry
Payments / Subscription Billing
FinTechSaaSTax
Compliance & Certifications
Qualified Invoice SystemElectronic Books Maintenance ActInstallment Sales ActASBJ Statement No. 29APPI

Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.

Impact

5 Screens
Clickable end to end

Dashboard, invoice runs, run detail with the qualified invoice preview and approval, furikomi matching with its receipt match panel, and dunning with its case panel.

6 Rules
Ranking every bank transfer

Virtual account, amount equal to an invoice, amount equal to a sum of invoices, learned payer name, kana name and short by a transfer fee, with deducted fees written off up to ¥880.

Once per Rate
Consumption tax rounding

Each invoice groups its lines by tax rate and rounds the tax down once per rate, as the Qualified Invoice System expects, and prints the issuer's T + 13 digit registration number.

24 Accounts
Realistic demo data

22 Japanese customers with 24 billing accounts on 6 closing days, 15 invoice runs, 15 open invoices, 14 bank receipts, 2 dunning policies, 12 dunning cases and 6 staff users.

The Problem

Hoshizora Cloud billed from a spreadsheet copied out of Salesforce each month and a card-only billing tool. Around 70% of revenue arrived by bank transfer, so two people spent four days every month-end building invoices by hand, matching transfers by reading katakana payer names in the bank's portal and chasing customers who had deducted the transfer fee. Month-end close took 9 working days and the auditors flagged revenue timing twice.

Our Solution

Tsumugi runs billing the way Japanese B2B customers expect to be billed: one qualified invoice per billing account per closing date, checked before anything is sent and approved by someone other than the preparer, a virtual account per billing account so transfers match on their own, a matching screen for the rest, and dunning steps set by payment method.

The Challenge: Billing the Japanese Way

Most of Hoshizora Cloud's 2,400 customers, from 20-person clinics to retail chains with 300 stores, pay by bank transfer against an invoice issued on their own closing date, and every one of those invoices has to meet the Qualified Invoice System.

Transfers Matched by Eye

Payer names arrive in half-width katakana with legal-form abbreviations such as カ), often without a reference, and customers deduct the transfer fee when their terms say they bear it. Finding the right invoice meant searching by amount and guessing at names.

A Qualified Invoice Every Time

Since October 2023 an invoice must show the issuer's registration number, the totals and consumption tax per rate and the recipient, with tax rounded once per rate rather than per line. Credits of ¥10,000 or more need a qualified return invoice.

Billing by Closing Date

Customers expect one invoice per closing date (締め日), commonly month-end or the 20th, with payment due on a set day such as the end of the next month and moved for bank holidays. Mid-month seat changes still have to be prorated the same way every time.

Revenue and Records Auditors Trust

Annual prepayments were booked as revenue on the day they were invoiced instead of over the service period under ASBJ Statement No. 29, and the Electronic Books Maintenance Act requires issued invoices to be stored unchanged and searchable by date, amount and counterparty.

Our Approach: From Billing Rules to a Clickable Platform

01

Spec and Rules Research

Mapped 6 user roles, 45 screens across staff, customer portal and public pages, and the data model for customers, billing accounts, versioned plans and prices, subscriptions, usage, invoice runs, invoices, credit notes, payments, dunning cases and revenue schedules. Wrote down the rules the design follows: the Qualified Invoice System and return invoices, consumption tax rates and rounding, closing dates and payment terms, virtual accounts and transfer fees, the Installment Sales Act and 3-D Secure, the Electronic Books Maintenance Act, ASBJ Statement No. 29 and the APPI.

02

Clickable Demo on a Production UI Kit

Built 5 key screens on a production dashboard kit: the dashboard with MRR, ARR, churn and retention, MRR movements, A/R ageing by payment method and cash expected; invoice runs with a closing-date calendar and Build run; the run detail with pre-flight checks, the qualified invoice preview, exclude, rebuild and approve and issue; furikomi matching; and dunning with promises, pauses and service suspension. All actions run on local state.

03

What a Production Build Adds

Integration with a card gateway (such as Stripe, GMO Payment Gateway or PAY.JP), convenience-store payment, virtual accounts through a bank API or Zengin-format files, freee or Money Forward journals, Salesforce or kintone, the National Tax Agency registration check, Peppol (JP PINT), email delivery and a certified timestamp service. Staff roles with approval limits, an append-only audit log, documents kept for 10 years, and the remaining screens: customers, catalogue, quotes, subscriptions and proration, usage, credit notes, revenue, reports, settings, the customer portal and the public quote and pay pages.

Why It Works: Nothing Leaves Unchecked

Runs Follow Closing Dates

Invoice runs are built per closing date, with the billing accounts closing on each one shown in a calendar strip. Pre-flight checks cover usage imports, pending changes, addresses, negative totals, the registration number, movements over 30% and missing PO numbers, and the preparer cannot approve their own run.

The Invoice Is Seen Before It Is Sent

Any invoice in a run opens as the qualified invoice the customer will receive: 請求書, the addressee with 御中, the issuer block with its T number, closing and due date, virtual account payment details and the totals per tax rate.

Matching That Reads Katakana

Payer names are normalised from half-width katakana with legal-form prefixes removed, then candidate invoices are ranked with the rules that matched. The difference comes with its treatment: write off as transfer fee within ¥880, leave as short, hold an excess as credit, or refund. A name matched once is learned for next time.

Dunning by Payment Method

Card and convenience-store customers get card retries on days 1, 3 and 7, a reminder email, a call task on day 10, a restriction notice on day 20 and suspension on day 30. Bank transfer customers skip the retries. A promise to pay or a pause moves the next step.

Related case studies

View all: Payments
Logo
Oceanlab

Enterprise Software Engineering - Human + AI

Languages

Locations

Global Headquarters

21 Merchant Road, 3rd Floor, Singapore 058267

Main corporate office and leadership operations

North America Office

548 Market Street, PMB 12345, San Francisco, CA 94104

Client operations and business development

India Office

402 Shivalik Shilp II, SG Highway, Ahmedabad 380015

Engineering and delivery center

© 2026 - Copyright. All Rights reserved Oceanlab