Digitalization of Small and Medium Enterprises through Core Invoice

Visits: 19

Nobuyuki SAMBUICHI
ISO/TC295 Audit data services/SG1 Semantic model Convener

The Japanese version of Core Invoice was named inspired by the European standard Core Invoice. The European standard Core Invoice is the standard format for electronic invoices used in Europe.

This article introduces the background of business requirements and key technical points of implementation for the XBRL Japan’s POC (Proof of Concept).

The Core Invoice Gateway trial version is available from the following URL, provided by Sambuichi Professional Engineers Office:
https://www.wuwei.space/core-japan/

The Journal Entry Search Exclusive Browser trial version is available from:
https://www.wuwei.space/core-japan/journal_entry/

Those interested in syntax binding should continue reading, including section 6.

The standard format CSV is defined as Hierarchical Tidy Data. In Tidy data:

Tidy data is a standard way of mapping the meaning of a dataset to its structure. A dataset is messy or tidy depending on how rows, columns and tables are matched up with observations, variables and types. In tidy data:

Each variable forms a column.

Each observation forms a row.

Each type of observational unit forms a table.

— Hadley Wickham
Tidy Data Journal of Statistical Software August 2014

You can download original paper from the following
https://www.jstatsoft.org/article/view/v059i10

For more information on Hierarchical Tidy Data, please refer to the following articles:
Hierarchical Tidy Data and Data Transformation
A New Era of Data Transformation: Hierarchical Tidy Data.
Kindly check both for a comprehensive understanding.

1. Is JP PINT a Panacea?

With the spread of electronic invoicing, standardization of accounting data and information sharing have advanced, leading to expectations for efficiency improvements in the tasks of accountants and businesses. This facilitates centralized data management, reduction of errors, and makes information search and analysis easier, thus enabling efficient business management and cost reduction.

Status of Initiatives Regarding Electronic Invoices

— IT Strategic Headquarters of the Cabinet Secretariat
December 9

Source: Status of Initiatives Regarding Electronic Invoices Cabinet Secretariat IT Strategic Headquarters, December Reiwa 2

Efforts Toward the Popularization of Digital Invoices

— Digital Agency
March Reiwa 4

Source: Efforts Toward the Popularization of Digital Invoices Digital Agency, March Reiwa 4

In December of Reiwa 2, the IT Strategic Headquarters of the Cabinet Secretariat announced the adoption of Peppol, one of the standards for international e-commerce networks, to standardize the specifications of electronic invoices. In October of Reiwa 4, the first version of the Japanese edition of Peppol (JP PINT) was released, and its operations are supervised by the Digital Agency.

As shown in Figure 1, JP PINT service providers only accept electronic invoices from OpenPeppol, limiting their scope.

OpenPeppol’s jurisdiction is from C2 to C3, so the connection between businesses and access points depends on the provider. For instance, if a C2 provider offers a connection with the Small and Medium Enterprise Common EDI, as depicted in Figure 2, Business Z (C1), even if they use the SME Common EDI, can send a converted electronic invoice to Business Y (C4). This setup is similar to when accounting software supporting JP PINT connects to OpenPeppol through a provider.

Specifically, as illustrated in Figure 3, by using a gateway that converts data between different formats like the Small and Medium Enterprise Common EDI and JP PINT, businesses participating in the SME Common EDI can also connect to Peppol, a global electronic invoice network.

Playing a crucial role here is “syntax binding.” In the eInvoice of the CEF (Connecting Europe Facility) that aims for a unified European market, syntax binding is provided to integrate various electronic invoice formats used in different systems or countries. This allows companies and public entities to exchange electronic invoices of different formats using common data items, thereby improving data interoperability.

To interconnect various electronic invoices, a “Japanese Core Invoice Model” is necessary, covering all electronic invoices including EDI. Based on its standard data item definitions, the “Japanese Core Invoice Gateway” can be used to mutually convert different syntaxes, enabling interconnectivity.

The Japanese Core Invoice Gateway is currently being tested and can be accessed [here](https://www.wuwei.space/core-japan/).

The Japanese Core Invoice Gateway is also a handy tool for small and medium-sized businesses to use electronic invoices.

2. Think of it as Cargo Ship Container Transshipment

To understand the Core Invoice system, imagine the transshipment of containers in cargo ship transportation.

The Core Invoice system is designed to handle invoices represented in different data formats, such as the Small and Medium Enterprise Common EDI or JP PINT, in a standardized and uniform format. Picture a port where containers are being transshipped. According to a picking list, various details like the invoiced amount, product names, quantities, prices, and tax rates are extracted and stored in designated cargo holds, albeit in different configurations.

This task is performed by automated cranes, which operate based on directives given in the standard data item definitions of the Core Invoice, picking sheets, and storage instruction lists. These instructions are represented using a taxonomy-defined dictionary.

In essence, the Core Invoice system standardizes various data formats, enabling efficient invoice processing. The Japanese Core Invoice Gateway provides the functionalities necessary for this system. Just like transshipping containers with automated cranes, it converts invoices of various formats into one standardized format, managing them uniformly.

3. Syntax Binding

Syntax binding refers to the rules and procedures for converting data of different formats into a unified format. This allows for easy acquisition and setting of electronic invoice information.

For example, suppose different companies use different formats to represent certain information. One company might represent information in the order of “product name-quantity-price”, while another might use “quantity-product name-price”. In such cases, because the way the same information is expressed differs, each requires a different reading method, and constantly changing the reading method (or modifying the program) is inefficient. Hence, syntax binding is introduced to establish specific rules and procedures, such as unifying to the “product name-quantity-price” format. This allows information from any company to be read in the same way, enabling efficient handling of information.

In Europe, based on the Directive 2014/55/EU of the European Parliament and the Council, the European standard EN 16931 series has been defined, and the promotion of digital invoicing is underway. As of 2014, each member state was promoting eInvoice and eProcurement centered on government procurement, but cross-border transactions were hindered because each country adopted different standards. The European Parliament defined the minimum common elements of electronic invoices as “core elements of electronic invoices” and decided to specify “syntax binding” by selecting from the XML syntax adopted in each country.

Syntax Binding

— Martin Forsberg
eInvoicing from a user’s perspective

JP PINT has adopted UBL, and the common EDI for small and medium-sized enterprises adopts UN/CEFACT CII. Although there are common elements in each syntax binding, the element names and structures of UBL and CII differ, requiring mapping. European standards define a logical model in EN 16931-1, specify syntax binding in CEN/TS 16931-3-1, and define syntax binding with UBL in 16931-3-2 and with UN/CEFACT CII in 16931-3-3.

For instance, the element corresponding to the issuer of the invoice in UBL is cac:AccountingSupplierParty, and in CII, it’s ram:SellerCITradeParty. To map these, the Japanese core invoice gateway defines “seller” in the logical model and defines syntax binding for that item to UBL and CII.

CEN/TS 16393-3-1 also describes cross-mapping between XML syntaxes. Issues with mapping can result in information loss. Mapping issues can arise at the logical level, structural level, difference in repetition levels, or data type level. Mapping is a crucial means to enable binding between different syntaxes. Accurate mapping can minimize information loss.

For the invoice number BT-1 defined in EN 16931-1 (A unique identification of the Invoice.), in UBL 2.1 it corresponds to /Invoice/cbc:ID, and in UN/CEFACT CII 16B it corresponds to /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:ID.

Syntax binding based on European standards allows data exchange between business systems and XML documents by reading and writing XML element values at specific positions in the XML document.

The Japanese version of the core invoice encompasses all necessary electronic invoice items in the logical model and defines the relationship between each syntax (such as Peppol’s JP PINT invoice or the common EDI for small and medium-sized enterprises’ UN/CEFACT CII) in XPath. This information is managed in the business dictionary (taxonomy), allowing for easy management of logical model updates and revisions to the electronic invoice syntax.

It may also be necessary to utilize past accounting data. While detailed discussions are still underway, from a digitization perspective, it’s important to effectively use these accumulated data. Using a business dictionary (taxonomy), you can use accumulated electronic data in comparison with the business dictionary (taxonomy) at that time. In the business dictionary (taxonomy), not only nationwide standard definitions but also unique definitions for each company must be linked and managed.

For more details, please check Detailed Explanation of Syntax Binding.

4. Journal Entry Information Search Browser

In the Japanese version of Core Invoice Gateway, you can combine multiple interfaces to facilitate integration with internal systems. As an example, we introduce a “Journal Entry Information Search Browser” using syntax binding.

The Journal Entry Information Search Browser is a prototype service that extracts data from accounting software and converts it into a more easily verifiable form. It is available from here.

Figure 1. Journal Ledger

Most accounting software has a feature to export data in CSV format. This browser takes that function and evolves it into a more convenient form. Firstly, it converts the CSV file exported from the accounting software into a standard CSV format currently being revised under ISO/TC 295 Audit Data Services. From this standard format CSV, it automatically generates and displays the “Journal Ledger,” “General Ledger,” and “Trial Balance.”

What’s more convenient is that unique information specific to accounting software or the user can also be registered in this standard format CSV using the Hierarchical Tidy Data format.

For instance, the CSV exported from the accounting software might have unique management items such as “Tax Information,” “Asset Classification,” “Cost Department,” “Transaction Financial Institution,” “Supplier,” and “Customer.” These items are listed in specific CSV columns, and without a dedicated program to extract those columns, it would be impossible to verify. The Journal Entry Information Search Browser converts these custom items into the standard format CSV based on the syntax binding definition table, so you can verify it on a unified interface without modifying the program.

The Journal Entry Information Search Browser is a service that transforms data from accounting software into a more user-friendly standard format CSV regardless of vendor or version differences and allows centralized verification. For example, even CSVs outputted by software no longer provided from over 10 years ago can be converted into standard format CSV if there is a data definition specification. By defining a syntax binding, it enhances the accessibility and convenience of accounting data significantly.

For more details, please check Journal Entry Information Search Browser and Logical Binding.

5. Digitalization of Accounting Initiated by Electronic Invoices

The digitalization of accounting, spurred by electronic invoices, is crucial.

For small and medium-sized enterprises (SMEs), the Japanese Core Invoice Gateway and syntax binding are vital tools. The Japanese Core Invoice Gateway uniformly processes invoices of different formats, promoting advanced invoice processing. Syntax binding aims to improve business efficiency by automatically extracting data and processing it as standard format invoices containing accurate information.

Through the standardization of accounting data (Standard Format CSV), SMEs can also enhance their business relationships with partners. By using a common interface, as shown in the figure above, data exchange becomes smoother, and communication with partners becomes more seamless. Additionally, the standardization of accounting data can lead to increased efficiency and accuracy in accounting processes.

The structure and meaning of the Standard Format CSV file are defined by taxonomy. By synchronizing with taxonomy maintenance and change management, it’s also possible to automate system maintenance.

By providing advice and support on the standardization of accounting data and the introduction of a common interface, we can contribute to the management of companies. So, why not consider standardizing your accounting data (Standard Format CSV)?

6. Explanation for XML Technologists

6.1. Logical Model of Digital Invoice

The logical model of a digital invoice is a method of structuring and representing invoice information in a standardized format. This enables efficient retrieval and processing of the information. In data structuring, groups with common data structures such as business entities, addresses, periods, transaction details, product information, prices, and tax information are defined and represented in a hierarchical structure.

6.2. Elements of Digital Invoice

Invoice Number
Invoice Date
Issuer Information
– Company Name
– Address
– Phone Number
– Email Address
Recipient Information
– Company Name
– Address
– Phone Number
– Email Address
Product/Service Information
– Description
– Quantity
– Unit Price
– Amount
Tax Amount
Total Amount Including Tax
Payment Information
– Payment Due Date
– Payment Method

With such a hierarchical structure, the information in the digital invoice is standardized and can be processed efficiently. Additionally, each item is defined using data types and code lists that comply with industry standards, enabling easy data exchange between different systems and companies. As digital invoices become more prevalent, businesses can achieve efficient accounting processing and tax filing, resulting in improved operational efficiency and cost savings.

For a qualified invoice, the following items are required:

Name or designation and registration number of the issuer of the qualified invoice
Date of the transfer or provision of taxable assets
Description of the asset or service subject to the transfer or provision of taxable assets (if it’s a reduced tax rate asset, the details and indication of such)
Total amount of the price either without tax or with tax, divided by tax rate, and applicable tax rate
Tax amount divided by tax rate
Name or designation of the recipient of the document

These items are included in the digital invoice’s logical model, which is defined in the following hierarchical structure:

Invoice
– Invoice Number
– Invoice Date
Seller
– Name or Designation (1)
– Registration Number (1)
Buyer
– Name or Designation (6)
Tax Information by Rate – repeated multiple times
– Total Amount (4)
– Applicable Tax Rate (4)
– Tax Amount (5)
Line Items – repeated multiple times
– Date of Transfer (2)
– Product/Service Information (3)
– Tax Category and Rate for Product/Service (3)
– Quantity, Unit Price, Amount for Product/Service

This hierarchical definition is the logical model.

Let’s now represent the example from the National Tax Agency’s Q&A No. 45 about qualified invoices using the logical model.
Note: The total amounts and tax totals are corrected based on the line items listed in the Q&A.

Q&A No.45
Source: Requirements for Entries in Qualified Invoices

The table that maps this data to the logical model’s hierarchical structure is presented next.

Item Name	C1	C2	C3	C4	C5	C6
Invoice Number	156
Invoice Issue Date	2023-12-01
Invoice Start Date	2023-11-01
Invoice End Date	2023-11-30
Seller Registration Number(1)	T1234567890123
Seller Name(1)	Company △△ Trading
Buyer Name(6)	Company 〇〇
Total of Invoice Detail Line	17000
Invoice Total Amount (Excluding Tax)	17000
Invoice Consumption Tax Total Amount	1400
Invoice Total Amount (Including Tax)	18400
Net Invoice Amount	18400
Tax Breakdown(1..n)		1	2
* Tax Basis Amount by Classification(4)		15000	2000
* Consumption Tax Amount by Classification(5)		1200	200
* Tax Classification Code(4)		AA	S
* Tax Rate by Classification(4)		8	10
Invoice Detail Line(1..n)				1	2	3
* Invoice Detail Line ID				1	2	3
* Invoiced Quantity				1	1	1
* Invoice Detail Line Amount (Excluding Tax)				5000	10000	2000
* Invoice Detail Line Start Date(2)				2023-11-01	2023-11-01	2023-11-02
* Invoice Detail Line End Date(2)				2023-11-01	2023-11-01	2023-11-02
* Product Name(3)				Wheat Flour	Beef	Kitchen Paper
* Product Tax Classification(3)				AA	AA	S
* Product Tax Rate(3)				8	8	10
* Product Unit Price (Excluding Tax)				5000	10000	2000

This table is described in a format called Hierarchical Tidy Data. Hierarchical Tidy Data is a method of listing document-level data and repeated detail lines in one table, with the following characteristics:

Each row represents a single observation, and each column represents a single variable.
Each table corresponds to a single observation unit, and the data is recorded in one table without being divided.
Each detail line’s data is expressed using the same variable name as the document-level data, and a new row is added for each detail line.
For example, in this table, document-level data such as invoice numbers and billing periods are expressed in a single row, while data repeated in detail lines, such as taxable amounts and consumption tax amounts by tax classification, are expressed in multiple rows.

By using Hierarchical Tidy Data, data processing and aggregation become easier, and it’s more convenient to apply data visualization and machine learning. For instance, with this table, you can aggregate taxable amounts and consumption tax amounts by tax classification for detail lines with the same invoice number into one table or visualize sales by seller names for specific buyer names.

In this way, Hierarchical Tidy Data standardizes data handling, making data management and analysis easier, and is useful for business decision-making.

For example, when analyzing a company’s financial data, you need to process and refine the data. However, the data in Hierarchical Tidy Data is in an easy-to-process format, which can streamline the data analysis process. Furthermore, by adopting standard formats like XBRL-CSV, it becomes easier to share data between multiple companies. This allows for data visualization and analysis across the entire industry, leading to deeper insights and business opportunities.

Invoice Number	Tax Breakdown(1..n)	Invoice Detail Line(1..n)	Invoice Issue Date	Invoice Start Date	Invoice End Date	Seller Registration Number(1)	Seller Name(1)	Buyer Name(6)	Total of Invoice Detail Line	Invoice Total Amount (Excluding Tax)	Invoice Consumption Tax Total Amount	Invoice Total Amount (Including Tax)	Net Invoice Amount	Tax Basis Amount by Classification(4)	Consumption Tax Amount by Classification(5)	Tax Classification Code(4)	Tax Rate by Classification(4)	Invoice Detail Line ID	Invoiced Quantity	Invoice Detail Line Amount (Excluding Tax)	Invoice Detail Line Start Date(2)	Invoice Detail Line End Date(2)	Product Name(3)	Product Tax Classification(3)	Product Tax Rate(3)	Product Unit Price (Excluding Tax)
156			2023-12-01	2023-11-01	2023-11-30	T1234567890123	Company △△ Trading	Company 〇〇	17000	17000	1400	18400	18400
	1													15000	1200	AA	8
	2													2000	200	S	10
		1																1	1	5000	2023-11-01	2023-11-01	Wheat Flour	AA	8	5000
		2																2	1	10000	2023-11-01	2023-11-01	Beef	AA	8	10000
		3																3	1	2000	2023-11-02	2023-11-02	Kitchen Paper	S	10	2000

This table is described in a format called Hierarchical Tidy Data. Hierarchical Tidy Data is a format for describing data in units of documents…

This table is described in a format known as Hierarchical Tidy Data. Hierarchical Tidy Data represents document-level data…

6.3. XML Syntax and XPath

Digital invoices are XML document data. The application of a logical model to XML syntax and the association of the resulting XML file with the values of the corresponding XML elements is referred to as “syntax binding”. In syntax binding, it is necessary to specify the location in the XML document where the data is defined in order to associate the items defined in the logical model with the XML elements. The specification of the position of XML elements in an XML document is called XPath. Next, let’s briefly introduce XPath. Below is a fictional example of the definition of a ComplexType in XML syntax. Consider an invoice that includes multiple products or services. The logical model of the document to be defined is as follows:

Invoice Invoice
* InvoiceHeader Invoice Header
** InvoiceNumber Invoice Number
** InvoiceDate Invoice Date
...

* InvoiceLine Invoice Line (repeated multiple times)
** ItemName Product Name
** Quantity Quantity
** Price Price
...

Based on the hierarchical definition of this logical model, the definition of the XML syntax (XML Schema) ComplexType (xs:complexType definition) is shown next:

<xs:complexType name="InvoiceType">
  <xs:sequence>
    <xs:element name="InvoiceHeader" type="InvoiceHeaderType"/>
    <xs:element name="InvoiceLine" type="InvoiceLineType" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="InvoiceHeaderType">
  <xs:sequence>
    <xs:element name="InvoiceNumber" type="xs:string"/>
    <xs:element name="InvoiceDate" type="xs:date"/>
    <xs:element name="..." type="..."/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="InvoiceLineType">
  <xs:sequence>
    <xs:element name="LineNumber" type="xs:string"/>
    <xs:element name="ItemName" type="xs:string"/>
    <xs:element name="Quantity" type="xs:decimal"/>
    <xs:element name="Price" type="xs:decimal"/>
    <xs:element name="..." type="..."/>
  </xs:sequence>
</xs:complexType>

In the above example, the InvoiceType is the top-level element, containing the InvoiceHeaderType and InvoiceLineType. The InvoiceLineType, specified with the maxOccurs attribute as “unbounded”, can contain multiple InvoiceLine elements. Also, both InvoiceHeaderType and InvoiceLineType can include elements like ItemName, Quantity, and Price.

Next is a digital invoice XML document created based on this XML Schema definition:

<Invoice>
  <InvoiceHeader>
    <InvoiceNumber>abc-123</InvoiceNumber>
    <InvoiceDate>2023-12-011</InvoiceDate>
  </InvoiceHeader>
  <InvoiceLine>
    <LineNumber>1</LineNumber>
    <ItemName>Wheat Flour</ItemName>
    <Quantity>1</Quantity>
    <Price>5000</Price>
  </InvoiceLine>
  <InvoiceLine>
    <LineNumber>2</LineNumber>
    <ItemName>Beef</ItemName>
    <Quantity>1</Quantity>
    <Price>10000</Price>
  </InvoiceLine>
</Invoice>

If you want to extract what is described in the second detail defined in this XML document, you would use XPath. In XPath, you specify which element’s descendant elements by using the format /parent element/child element/grandchild element. To specify the line of details in the above XML document, you would write /Invoice/InvoiceLine. This specification will select the two detail lines. Then, what does the following XPath indicate?

/Invoice/InvoiceLine[LineNumber=2]

This XPath specifies the two detail lines with /Invoice/InvoiceLine, but it also uses the condition described within [ ] to specify which detail line meets certain criteria. Here, it specifies the InvoiceLine element among several, where its child element LineNumber has a value of 2.

In this way, using XPath, you can clearly specify specific elements in an XML document. XPath is used to specify where to set the data defined in the logical model extracted from accounting software or business software in an XML document or when extracting necessary data defined in a logical model from an XML document.

Another example: The AllowanceCharge element has a child element called ChargeIndicator. When ChargeIndicator is set to “false”, this element is treated as a “refund”. On the other hand, when ChargeIndicator is set to “true”, this element is treated as an “additional charge”. In XPath, by writing AllowanceCharge[ChargeIndicator=false()], you can select the AllowanceCharge element (refund) where ChargeIndicator is set to “false”. Additionally, by writing AllowanceCharge[ChargeIndicator=true()], you can select the AllowanceCharge element (additional charge) where ChargeIndicator is set to “true”. In this way, using XPath to specify conditions, you can define the correspondence between different XML syntaxes.

By using XPath, specific elements within an XML document can be clearly identified. This is especially useful when designating where data, defined in a logical model extracted from accounting or business software, should be placed in an XML document. Additionally, it assists in extracting necessary data defined in the logical model from the XML document.

For instance, the AllowanceCharge element has a child element called ChargeIndicator. When ChargeIndicator is set to “false”, it is treated as a “refund”. Conversely, when it’s set to “true”, it’s regarded as an “additional charge”. With XPath, by writing AllowanceCharge[ChargeIndicator=false()], you can select the AllowanceCharge elements that are set to “false” (refunds). Likewise, by writing AllowanceCharge[ChargeIndicator=true()], you can select the AllowanceCharge elements set to “true” (additional charges). In this manner, XPath allows one to specify conditions and define the correspondence between different XML syntaxes.

Taking these issues into account, improvements in JP PINT are being called for. In future versions, it is anticipated that appropriate condition specifications based on an understanding of XML will be implemented. By leveraging XPath to specify the right conditions and define the relationship between different XML structures, enhancements in JP PINT are expected.

7. Basics of XML Syntax and XPath

XML is a language used to structure and describe data, widely utilized for exchanging information over the internet. XPath is a language designed to access specific elements or attributes within an XML document. This document will provide a straightforward explanation of the basics of XML syntax and XPath, even for beginners.

7.1. Fundamentals of XML

In XML, data is structured by enclosing it within tags, known as elements. Below is a simple example of an XML document.

<book>
  <title>XML for Beginners</title>
  <author>Taro Yamada</author>
  <price>1500</price>
</book>

In this example, the <book> element contains child elements: <title>, <author>, and <price>.

7.2. Basics of XPath

With XPath, you can access specific elements or attributes within an XML document. Below is an XPath example to select the <author> element from the previously shown XML document.

/book/author

This XPath specifies the <author> element, which is a child of the <book> element.

7.3. Utilizing XML Syntax and XPath

Using XML syntax and XPath makes adding, modifying, and searching data much easier. Consider the following XML document as an example.

<books>
  <book id="1">
    <title>XML for Beginners</title>
    <author>Taro Yamada</author>
    <price>1500</price>
  </book>
  <book id="2">
    <title>HTML for Beginners</title>
    <author>Jiro Sato</author>
    <price>1800</price>
  </book>
</books>

For this XML document, you can search data using the following XPaths:

To select all <book> elements: /books/book
To select the <book> element with the id attribute of 1: /books/book[@id=’1′]
To select the <title> element of all <book> elements: /books/book/title

In this manner, by using XML syntax and XPath, you can easily search and organize data. It allows even beginners to understand and manipulate data structures in a comprehensible manner.

8. Detailed Explanation of Syntax Binding

8.1. JP PINT Syntax Binding

The following table extracts the syntax binding of the tax amount group by tax category described in the currency of the invoice.
Here, to specify the tax amount group by tax category written in the currency of the invoice /Invoice /cac:TaxTotal, it is conditioned that the currency of the tax amount is the document currency of the invoice.
The following is that condition:

[cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode]

This XPath expression specifies /Invoice /cac:TaxTotal where the cbc:TaxAmount sub-element’s @currencyID attribute matches the document-level specified document currency code /Invoice /cbc:DocumentCurrencyCode.

/Invoice /cac:TaxTotal [cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode]

core_id	level	項目名	繰返し	Id	Level	Business Term ja	Card.	UBL XPath
NC39-NC57	2	文書ヘッダ課税分類	1..n	IBG-23	1	税内訳情報	1..n	/Invoice /cac:TaxTotal [cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode] /cac:TaxSubtotal
NC57-01	3	文書ヘッダ課税分類税額	1..1	IBT-117	2	課税分類毎の消費税額	1..1	/Invoice /cac:TaxTotal [cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode] /cac:TaxSubtotal /cbc:TaxAmount
NC57-03	3	文書ヘッダ課税分類譲渡資産合計金額（税抜き）	1..1	IBT-116	2	課税分類毎の課税基準額	1..1	/Invoice /cac:TaxTotal [cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode] /cac:TaxSubtotal /cbc:TaxableAmount
NC57-04	3	文書ヘッダ課税分類コード	1..1	IBT-118	2	課税分類コード	1..1	/Invoice /cac:TaxTotal [cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode] /cac:TaxSubtotal /cac:TaxCategory /cbc:ID
NC57-07	3	文書ヘッダ税率	1..1	IBT-119	2	課税分類毎の税率	0..1	/Invoice /cac:TaxTotal [cbc:TaxAmount /@currencyID = /Invoice /cbc:DocumentCurrencyCode] /cac:TaxSubtotal /cac:TaxCategory /cbc:Percent

The section of the electronic invoice corresponding to this syntax binding specification is shown next:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
    xmlns:ccts="urn:un:unece:uncefact:documentation:2"
    xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
    xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2"
    xmlns:udt="urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

…

    <cac:TaxTotal>
        <cbc:TaxAmount currencyID="JPY">25250</cbc:TaxAmount>        <!-- IBT-110 - Invoice total TAX amount -->
        <cac:TaxSubtotal>            <!-- IBG-23 - TAX BREAKDOWN -->
            <cbc:TaxableAmount currencyID="JPY">252500</cbc:TaxableAmount>            <!-- IBT-116 - TAX category taxable amount -->
            <cbc:TaxAmount currencyID="JPY">25250</cbc:TaxAmount>            <!-- IBT-117 - TAX category tax amount -->
            <cac:TaxCategory>
                <cbc:ID>S</cbc:ID>                <!-- IBT-118 - TAX category code -->
                <cbc:Percent>10</cbc:Percent>                <!-- IBT-119 - TAX category rate -->
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>                    <!-- IBT-118, qualifier -->
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:TaxSubtotal>
        <cac:TaxSubtotal>            <!-- IBG-23 - TAX BREAKDOWN -->
            <cbc:TaxableAmount currencyID="JPY">3490</cbc:TaxableAmount>            <!-- IBT-116 - TAX category taxable amount -->
            <cbc:TaxAmount currencyID="JPY">0</cbc:TaxAmount>            <!-- IBT-117 - TAX category tax amount -->
            <cac:TaxCategory>
                <cbc:ID>E</cbc:ID>                <!-- IBT-118 - TAX category code -->
                <cbc:Percent>0</cbc:Percent>                <!-- IBT-119 - TAX category rate -->
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>                    <!-- IBT-118, qualifier -->
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:TaxSubtotal>
    </cac:TaxTotal>

And so on.

8.2. SME Common EDI Syntax Binding

The following table extracts the syntax binding of the tax amount group by tax category described in the currency of the invoice.
Here, to specify the tax amount group by tax category noted in the invoice’s currency /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax, it’s conditioned that the currency of the tax amount is the document currency of the invoice.
The following is that condition:

[ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode]

The XPath expression specifies /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax where the ram:CurrencyCode sub-element matches the document-level specified document currency code /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode.

/rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax [ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode]

core_id	level	項目名	繰返し	UN_CCL_ID	Level	項目名	繰返し	SME CII XPath
NC39-NC57	2	文書ヘッダ課税分類	1..n	UN01005996	5	文書ヘッダ決済／文書ヘッダ税グループ	1..n	/rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax [ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode]
NC57-01	3	文書ヘッダ課税分類税額	1..1	UN01005833	6	文書ヘッダ課税分類税額	1..1	/rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax [ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode] /ram:CalculatedAmount
NC57-03	3	文書ヘッダ課税分類譲渡資産合計金額（税抜き）	1..1	UN01005839	6	文書ヘッダ課税分類譲渡資産合計金額（税抜き）	1..1	/rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax [ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode] /ram:BasisAmount
NC57-04	3	文書ヘッダ課税分類コード	1..1	UN01005841	6	文書ヘッダ課税分類コード	1..1	/rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax [ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode] /ram:CategoryCode
NC57-07	3	文書ヘッダ税率	1..1	UN01007174	6	文書ヘッダ税率	1..1	/rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:IncludedCIILSupplyChainTradeLineItem /ram:SpecifiedCIILSupplyChainTradeSettlement /ram:ApplicableCITradeTax [ram:CurrencyCode = /rsm:SMEinvoice /rsm:CIIHSupplyChainTradeTransaction /ram:ApplicableCIIHSupplyChainTradeSettlement /ram:InvoiceCurrencyCode] /ram:RateApplicablePercent

The section of the electronic invoice corresponding to this syntax binding specification is shown next:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<rsm:SMEinvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:SMEinvoice"
    xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:31"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:31"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:31"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="urn:un:unece:uncefact:data:standard:SMEinvoice https://www.wuwei.space/core-japan/server/data/schema/data/standard/SMEinvoice.xsd">

…

        <ram:IncludedCIILSupplyChainTradeLineItem>
            <ram:SpecifiedCIILSupplyChainTradeSettlement>
                <ram:ApplicableCITradeTax>
                    <ram:CalculatedAmount>25250</ram:CalculatedAmount>
                    <ram:TypeCode>VAT</ram:TypeCode>
                    <ram:BasisAmount>252500</ram:BasisAmount>
                    <ram:CategoryCode>S</ram:CategoryCode>
                    <ram:CurrencyCode>JPY</ram:CurrencyCode>
                    <ram:RateApplicablePercent>10</ram:RateApplicablePercent>
                </ram:ApplicableCITradeTax>
                <ram:ApplicableCITradeTax>
                    <ram:CalculatedAmount>0</ram:CalculatedAmount>
                    <ram:TypeCode>VAT</ram:TypeCode>
                    <ram:BasisAmount>3490</ram:BasisAmount>
                    <ram:CategoryCode>E</ram:CategoryCode>
                    <ram:CurrencyCode>JPY</ram:CurrencyCode>
                    <ram:RateApplicablePercent>0</ram:RateApplicablePercent>
                </ram:ApplicableCITradeTax>

And so on.

9. Detailed Analysis of Journal Information Search Browser and Logical Binding

The Journal Information Search Browser can convert data output by accounting software (in CSV or XML format) into a standard format CSV. This transformation is conducted based on a rule called logical binding (standard CSV binding) definition.

Since this browser operates as a “generic program”, if the binding definition is set up correctly, it can handle data output from both past software and software that’s currently under development seamlessly. This means any data can easily be displayed in the browser.

Below is an example of the data output by accounting software.

Figure 2. Accounting Software Output CSV

Typically, the data produced by accounting software includes specific data items and customizable extended items. Historically, each of these needed to be processed individually by a program, making it necessary to have different programs based on the accounting software or its version in use.

However, with the Journal Information Search Browser, the binding definition (which establishes links between the data and the program) is made modular, allowing easy adjustments. This approach makes it possible to cater to various data types and versions without modifying the program itself. As a result, with the right binding definition in place, the system can accommodate all data formats.

The binding definition between the CSV provided by this accounting software and the standard format CSV is shown next.

Figure 3. Logical Binding (Standard CSV Binding)

The standard format CSV is a logical model with a clearly defined hierarchical structure. In contrast, the CSV output from accounting software has a flat structure. Therefore, the columns of this flat CSV are mapped to the items of the standard format CSV, determining which hierarchy each item belongs to.

Figure 4. Standard Format CSV

The standard format CSV is a logical model that defines a hierarchical structure. This concept contrasts with the typical flat-structured CSV output by regular accounting software. This hierarchical structure uses Hierarchical Tidy Data, allowing representation of multiple layers within a single CSV file.

This Journal Information Search Browser can display not only the previously mentioned ledger but also the following two screens according to the standard format CSV.

Figure 5. General Ledger

Figure 6. Balance Trial Sheet

10. Conclusion: Standard Format CSV = Hierarchical Tidy Data

The essence of the technology introduced in this article lies in the Hierarchical Tidy Data, which represents the logical hierarchical model as a standard format CSV.

Both the Core Invoice Gateway and the Journal Information Search Browser have adopted the Hierarchical Tidy Data as their standard format CSV. Furthermore, by utilizing the binding definition, they have enabled data conversion with existing systems. This means that there’s no need to modify the form of the integrated system, as was required for common API compatibility or common interface adaptations, allowing for efficient system integration.

The integration program operates as a “generic program.” This program can map various syntaxes and logical hierarchical models according to the binding definition and possesses the ability to read and write data from specific locations. As a result, inter-system integration becomes possible just by describing the binding definition, without having to modify existing software or systems.

It’s worth noting that the binding definition is managed in a business dictionary (taxonomy). This ensures consistent data integration, encompassing both past and future data. It not only maintains the consistency of the data but also enhances the system’s extensibility and flexibility.

三分一技術士事務所