Strengthen accounting/SFA development with corporate master dummy data Safely automate Corporate Number and invoice registration checks
Use corporate master dummy data aligned with the Corporate Number check digit and the qualified invoice issuer registration number format to test accounting, SFA, and sales-management system rollouts.
This content is a technical sample; the Corporate Number and registration number only follow the required format and are fictional. Do not use them as a substitute for verifying real companies or running credit checks.
Where corporate master dummy data helps
Corporate master data involves logic tied to systems such as the Corporate Number and invoice registration number, which tends to make test cases complex. A standard schema lets you reproduce the key use cases safely.
Rolling out sales-management and accounting systems
End-to-end tests for creating, updating, and deleting partner records (CRUD)
Verify billing-cycle calculation logic using the closing date and payment terms
Test order-blocking logic when the credit limit is exceeded
Verify duplicate-check logic for Corporate Numbers and registration numbers
Testing invoice-system implementations
Test format validation of the qualified invoice issuer registration number (T + 13 digits)
Test warning displays when issuing an invoice to an unregistered partner
Test integration with a registration-number lookup API (format validation only)
Mock data for SFA and sales management
Verify sales-targeting logic using industry, capital, and employee count
Test business-card management and CRM integration using contact details
Test dashboards and reports segmented by transaction status
Performance-test imports of large partner datasets
Sample corporate master schema
The corporate master schema covers everything from the Corporate Number and registration number to credit and payee bank details. Below are representative fields and references. Field names stay in Japanese even in the en-US locale, matching CSV headers used by Japanese accounting/SFA systems.
Field
Description
Reference
取引先ID
Unique partner identifier
Digit count and prefix can be adjusted to your internal partner-code scheme
法人番号
13-digit Corporate Number
Generated using the National Tax Agency's check-digit calculation method (unrelated to any real company)
法人名
Partner's company name
A fictional company name unrelated to any real company
業種
Partner's industry
An industry list based on the major categories of the Japan Standard Industrial Classification; change it with the industries parameter
資本金
Partner's capital (JPY)
Randomly generated within the capitalMin–capitalMax range
適格請求書発行事業者登録番号
Invoice registration number
Follows the invoice-system format "T + 13 digits"; adjust the registered share with invoiceRegisteredRatio
取引区分
Customer/supplier classification
One of three types — customer, supplier, or both; change it with the transactionTypes parameter
締日
Billing closing date
A closing date (end of month, the 20th, etc.) used for testing the billing/payment cycle
支払サイト
Days from the closing date to the payment date
Used to test payment-schedule calculation logic
与信限度額
Partner's credit limit
A fictional value for testing credit-management systems
振込先口座番号
Payee bank account number
A fictional number, e.g. starting with a fictional prefix, designed not to be mistaken for a real account
取引状態
Status such as active/suspended
Useful for testing terminated or dormant partner records
The Corporate Number is generated using the check-digit formula published by the National Tax Agency, but it is not a number that actually exists on the public lookup site. When testing integration with a partner-verification system, limit the scope to the format and check-digit validation that precedes any real-existence check.
Operational notes
1
Do not cross-check against real companies
The Corporate Number and company name are fictional data meant only for format validation. Do not cross-check them against a real corporate database or a public lookup site — limit use to format and logic testing.
2
Build check-digit validation logic
The last digit of the Corporate Number is calculated as a check digit, so it can be used for unit tests of input-validation features.
3
Vary the closing date and payment terms
Change the closing-date pattern and payment terms via parameters to mix partners with different billing cycles and verify aggregation logic.
4
Handle payee details carefully
The payee bank name and account number are fictional, but label the screens and materials clearly as "sample data" so they are not mistaken for a real account.
FAQ
Q. Does the Corporate Number actually exist?
A. It is generated using only the check-digit formula published by the National Tax Agency and is not a real Corporate Number. We do not verify it against the public lookup site, so an accidental match cannot be fully ruled out — please do not treat it as real data.
Q. Can I use this to test validation logic for the qualified invoice registration number?
A. Yes, for checking the "T + 13 digits" format. Since we do not verify registration numbers against the public lookup site, use a production-equivalent test account separately if you need to test real-existence verification via a web API.
Q. Can I customize the distribution of closing dates, payment terms, and credit limits?
A. Some adjustment is possible via parameters such as capitalMin/capitalMax and transactionTypes. For finer control over closing-date or payment-term distribution, post-process the generated CSV, or open a GitHub Issue to request a new parameter.
Q. Does the en-US locale output the same format?
A. Field names (Corporate Number, registration number, etc.) are specific to Japanese systems and stay the same in both locales. Surrounding UI copy, such as descriptions and industry labels, is translated into English in the en-US locale.
Accelerate accounting/SFA development with corporate master dummy data
Get partner data aligned with the Corporate Number check digit and invoice registration number format as CSV, JSON, or via the REST API. Combine it with customer master and invoice data for end-to-end B2B2C verification.