1. Overview:

rootledgerXML is an open, nonproprietary XML format for transferring transaction data between any two general ledgers.  The goal of this format is to achieve a two-directional path, both into and out of, every general ledger.

The primary goal of rootledgerXML is to discover and enumerate the fields (XML elements) required for general ledgers at an abstract level, and to declare unambiguous names and data types for those fields.  The schema identifies two sets of fields:

1.  a small set of field names inherent to general ledgers, and common to every general ledger, such as transaction date and amount, and 

2.  ~70 additional, optional fields chosen to successfully import or export data from as many general ledger packages as possible.  

It is a goal of this schema to identify empirically and objectively, those fields (elements) which achieve the greatest economic net gain.  This in turn depends on identifying those fields for which automation of G/L interfaces produces the greatest labor savings by the largest numbers of end users.

It is not a goal of rootledgerXML that the names or data types defined for each field will agree with the naming followed by any particular GL software, or their data types.  rootledgerXML also does not include a schema for Chart of Accounts or the definition of a ledger or reporting entity although those are required in any general ledger.

This schema adopts these doctrines:

1.  An XML schema for GL should have a flat structure, having no hierarchy beyond one level.

2.  An XML schema for GL should consist only of elements (no attributes), in order to facilitate parsing by applications that are cheaper and consume less resources than full XML parsers.

3.  No flat-file XML schema can serve every GL unless it contains a very large number of elements.  However, large numbers of elements consume excessive resources for string parsers.  Accordingly this XML schema for GL should therefore contain a limited number of elements.

4.  The optimal choice of elements to support, among all elements supported by various GLs, can be determined by empirical research in user populations.

5.  Under an assumption that each element added to the schema produces progressively less economic value, a cutoff must be made at some number of elements.  The scope of this schema is arbitrarily cut off at approximately 88 elements.

It is a goal of rootledgerXML to be processed efficiently by conventional string parsers, including dedicated C or Java parsers or scripting languages perl and python.  This goal is achieved with valid and well formed XML, enabling parsing by XML parsers but not requiring them.  rootledgerXML followed most of the 1999 SML subset.  This objective is served by a flat schema containing only elements.  No attributes, and no hierarchic structures, are incorporated into the schema. 

It appears possible, mechanically, to transform a rootledgerXML document having a flatfile structure into hierarchic structure having headers and rows with an XSLT transformation, and vice versa (see demo XSLT transformations).  That demo is only possible however, if you make assumptions such as that the first date encountered for a particular transaction is the same on every other detail row for that transaction. It is not possible to produce a hierarchic structure having headers and rows, without loss of information, if you attempt to move an element from the row to the header. It is logically correct that every hierarchic GL can be transformed to a flat GL by duplicating the data in headers to each detail row. But you cannot transform a flat GL instance to a two-tier GL instance.

I find procedural code much easier to write and much more functional than transformations written in the XSLT language.

a.   What is a General Ledger?

A general ledger is any piece of software, data structure, etc. that is capable of maintaining a history of your transactions for at least a year, with sufficient organization to produce income statements and balance sheets.  

There is a logical principle, that if you have a number in your P&L or Balance Sheet at 12/31/2000, it must be composed of some discrete finite number of components. Those components exist someplace in your transaction system. They are not ambiguous at all. A GL is that list of amounts, together with dates and various other tags.

Many larger business systems exist meeting the above requirements, which also support invoicing, purchasing, etc.   For purposes of this document, the term "general ledger" refers to that module or view or subset of any business software which is essential to maintaining the minimum data and functionality for producing income statements and balance sheets.

In practice, a GL is a set of double-entry transactions which balance.   Classic double-entry accounting (CDEA) is a comprehensive methodology and notation for recording transactions practiced by 100% of medium - large businesses worldwide (although admittedly, the double entry methodology is often either done automatically for the user or not done at all until report generation time.)  There are no theoretical designs or ideas that meet the minimum requirements for stewardship of information about assets and liabilities, and for reporting, that are not CDEA structures, or mathematically equivalent, or supersets of CDEA.  (ref)    rootledgerXML reflects this universal standard by declaring a standard, flat row structure.

Remember CDEA is really a user interface cult, or at best a semantic convention for communicating about transactions, for example their amounts and what impact resulted in your bottom line.  However,  B2B XML vocabularies describe countless diverse types of  business dealings more completely, more logically, and more accurately, than CDEA or rootledgerXML.

There are at least three styles of display or presentation of GL information in screens and reports: CDEA, headers with rows, and splits.  These three presentations are all equivalent, and can be converted interchangeably, without loss of information.

Example of three transactions within a G/L, with a CDEA user interface:

Example of three transactions, with a "headers and rows" style user interface:

Example of three transactions, with a "splits" style user interface:

Many business systems exist which maintain histories and produce financial statements, which do not use the term "General Ledger" anyplace, or display any of the 3 views above.  For example, they may consist of a set of dedicated listings for payments, sales, or receipts, etc. and the associated input screens, resulting in a set of financial statements.  Behind the scenes, in every case, these systems apply classic double entry accounting methodology when they deliver information to their GL module.  Their "innovation" is only an interface innovation.  They can be interfaced via rootledgerXML, i.e. they can deliver CDEA rows in every case, and quite often they contain no more data than the 88 fields of rootledgerXML.

b.  What is a webledger?

A webledger refers to any general ledger capable of maintaining transactions histories and producing income statements and balance sheets, which runs over the internet, i.e. capable of accepting transactions and delivering reports via a browser or thin client, XML files, etc.  Examples of commercial webledgers include Netledger, Intacct, Netaccount, etc.  Examples of open source webledgers include SQL-Ledger.

c.  What is a root ledger?

The term root ledger is synonymous for the master general ledger within any software architecture that has subsidiary journals or ledgers.  A sub-ledger might be any business application that generate transactions formatted as CDEA journal entries. In other words, if you have sub-ledgers, you have a root ledger.

For example, if you are only running Quickbooks or Peachtree or AccPac then you don't have a root ledger.  If you conduct business through BSPs on the internet, or you have unintegrated local software such as a POS system, and those systems provide you coherent CDEA ledger entries, and you manually enter the data into your GL, it is a root ledger scenario.  

As a practical matter a root ledger will often be a webledger having back-end XML integration with 3rd party BSPs or business modules, due to the high costs and risks of operating a rootledger on local business workstations, connected to multiple BSPs on the internet.

There are certain things you cannot get without a rootledger, in any scenario involving multiple, distributed business software or BSPs.  There are at least seven inherent requirements in a root ledger:

1. maintain fiscal control (e.g. control totals) over money and accounts receivable and payable that exist out on the remote BSPs and functional modules as well as local systems, fixed assets etc. 

2. maintain near-realtime information of cash balances, cash flow attributes of all events which have happened, and cash flow sources and needs predicted at future dates sufficient to manage the cash flows of the business.

3. consolidated views of accounts receivable / accounts payable sufficient to maintain control over supplier and customer balances when the enterprise touches those same classes of customers or suppliers thru multiple points (e.g. selling locally and on web storefront; buying locally and thru web purchasing portals)

4. GAAP financial statements / financial reporting

5. timely and accurate tax reporting

6. consolidations and eliminations whereever multiple sub-ledgers exist, including multiple "general ledgers" on BSPs as well as companies/locations.

7. foreign currency translations 

Any two or three of the above requirements make rootledgers with XML interfaces a certainty, in tomorrows' networked business environment.

d. Who needs a standard for GL data?

The need for a standard data format arises in many scenarios, for example:

1. The entity uses more than one general ledger (GL), one being the master GL (the root ledger) and the other(s) being sub-ledgers.  rootledgerXML provides a data format for transporting stacks of debits and credits to the root ledger, i.e. performing consolidations and eliminations of multi-department, multi-location, multi-currency or multi-company data.
   
2. The entity uses multiple business systems, running locally on the LAN or on the internet, which are not integrated with their general ledger.  rootledgerXML provides a data format for those unintegrated sub-systems or sub-ledgers to send transactions to the company's general ledger.  The metaphor of debit-credit transactions is well understood by every accountant and developer of business software systems.  There is a debit-credit formula or template for every type of transaction in the universe.
   
3. Owner of the data wishes to discontinue one accounting package or hosted service, and transfer data into another one, to continue doing business without interruption.  rootledgerXML is capable of conveying transaction history to or from any accounting system having export or import interfaces.  XML capabilities end the lock-in of users to accounting software. This schema helps make that possible at a practical level, without requiring custom XML transformations.
   

e. Why has there never been a G/L format in the past?

There has been a need for a standard format for GL data for at least 25 years, for all of the purposes above.   Workarounds evolved based on ASCII text and other solutions, for small systems.  There are many approaches for large systems including EDI, RDBMS links, etc. but they were expensive and usually custom. Vendors' design decisions in data interoperability, are optimized for their economic outcomes.  

Market demand for a truly global standard has not been sufficient, historically, to drive sales; accordingly the benefits of lock-in strategies which prevented data interoperability exceeded other strategies, and dominated software vendors' decisions.

f.  When will a standard G/L data format emerge?

A standard will emerge only when customers demand it.  To appreciate this fact, consider the experience of OAG, the Open Application Group.

A group of ERP vendors and manufacturers within OAG have developed a general ledger XML schema called "Post_Journal", which was followed by over 120 other types of XML transactions and framework schemas (POs, Invoices, etc.).  The OAGIS standards emerged from a lot of concentrated workgroups among software vendors, in response to requirements from large and sophisticated customers.  The OAGIS standard for General Ledger was the first schema they agreed upon, and it did not emerge naturally by cooperation among software vendors alone.  It emerged when Fortune 500 customers demanded interoperability.

The emergence of BSPs (business service providers) on internet is the factor which is triggering demand among Small and Midrange Enterprises (SMEs) for an XML standard for General Ledger.  Just as ERP offered a quantum leap in functionality to Fortune 500, the internet computing paradigm enables a quantum leap for SMEs.  BSPs will enable small business to send and receive invoices, orders and payments over the internet, saving billions of dollars in administrative costs.  SMEs need rootledgers to support distributed components such as BSPs, and rootledgers require GL schema optimized for A2A purposes.  

E-commerce (B2B) XML vocabularies cannot serve the function of GL messaging among the modules of a single company.  This task is called application-to-application (A2A) integration.  GL interface messages contain numerous fields which are unnecessary for 3rd parties or inappropriate to disclose in B2B transaction docs.  They contain dependencies on the individual company's systems and structure.

g.  What format will ultimately succeed in the marketplace?

The XML format that serves individuals and small business.  There are hundreds of millions of individuals and small businesses.  This will drive standardization in a direction that will affect large enterprises.

OAGIS Post_Journal is not entirely unsuitable for GL posting of individual spot commerce and SMEs' accounting systems.   In contrast, however, rootledgerXML includes many data elements which are quite common in smaller systems but omitted in Post_Journal.   RootledgerXML is furthermore, a flat structure while OAGIS is hierarchic; rootledgerXML uses natural spelling in mixed case, while OAGIS uses all uppercase "code names" limited to ten characters; rootledgerXML omits a few data elements of OAGIS which do not occur in sufficient frequency in SMEs to warrant inclusion.

OFX is also not entirely unsuitable for A2A GL integration, but does not contain sufficiently well rounded set of fields for General Ledger and furthermore, has a hierarchic structure, and is highly politicized.  Accordingly it will not be accepted by the market for rootledger purposes.  

2. Definition of rootledgerXML for General Ledger

The rootledgerXML fields or data elements, are described below.  These fields are  sufficient for storage of many types of transactions in CDEA rowsets.  Use cases are available on request; they are nothing surprising.  Intermediate accounting textbooks contain the CDEA formulas for every type of transaction that is possible in the economy; additional attributes provided below are sufficient to enable a star or snowflake storage schema that would handle most businesses. 

Very few companies will need more than 10 or 12 of these fields to interface with their General Ledger:  the rest of the fields are options provided for "somebody else":

	Fieldname	Required	Field description, usage, etc.  (rootledger v 0.8 draft)
1	Host		system, host or software which created this XML file
2	HostKey		The key, index, etc. from that host which enables drillback
3	OriginalHost		system, host or software which originally created these transactions
4	OriginalKey		The key, index, etc. from that subsystem responsible to enable drillback
5	Entity		QName same as XBRL entity; the entity which executed this transaction.
6	Division		middle level of organization hierarchy between Entity and Department.
7	Department		3rd and lowest level organization  unit supported in this schema
8	Section		4th and lowest level organization  unit supported in this schema
9	Country		ISO 3166 country dimension i.e. nation associated with transaction execution
10	Geographic		Top level geographic code or area the transaction is associated with.
11	GeographicSubarea		2nd and lowest geographic level supported in this schema
12	Language		ISO 639-1998 e.g. "en", "fr", etc.
13	Journaltype		sales journal, purchase journal, etc
14	TransactionID		uniquely identifies this transaction (set of rows)
15	TransactionRowID		uniquely identifies this row (e.g. line of journal)
16	TransactionRowCount		how many rows in this transaction.
17	TransactionDate	Yes	ISO 8601"YYYY-MM-DD" only.  date of transaction execution
18	TransactionTime		ISO 8601 time "hh:mm:ss" only
19	TransactionTimeZone		timezone ISO 8601 "(+ or -)hh:mm" only
20	TransactionType		values A,B,T, or F (Actual, Budget, Forecast, TaxAdjustment) (for tax differences use multiple types and rows)
21	TransactionBatchID		associates this TransactionID with a batch
22	TransactionPostDate		Date requested by subledger to post this transaction, or date posted if posted.
23	PostedStatus		zero if not posted; 1 if posted.
24	Period		accounting period
25	TaxTypeCode		taxable scheme, rate, category, etc. (for multiple tax entries use multiple rows)
26	EliminationsCode		Code informs destination ledger this is an intraco. entry which eliminates in consolidation
27	EnteredDate		ISO 8601"YYYY-MM-DD" only- the date the transaction was entered to the system.
28	EnteredTime		ISO 8601 time "hh:mm:ss" only
29	EnteredTimeZone		timezone ISO 8601 "(+ or -) hh:mm" only
30	User		authenticated user recorded this transaction
31	UserSignature		digital signature of user
32	Employee		internal party associated with this transaction
33	Approved		0=no, 1=yes to mark this row as internally approved or authorized.
34	Reviewed		0=no, 1=yes to mark this row as review by some external auditor or reviewer
35	Reference		source doc. number or index, etc. general purpose reference to source docs.
36	Reference2		source doc. number or index, etc. -some systems carry two ref. fields.
37	Party		QName (namespace:id) uniquely identifies the reciprocal party to this transaction
38	PartyRole		role or type of party as customer, supplier, etc.
39	PartyContact		uniquely identifies individual within the reciprocal party
40	PartySignature		digital signature of Party
41	Party2		QName (namespace:id) uniquely identifies the reciprocal party to this transaction in another namespace
42	Party3		QName (namespace:id) uniquely identifies the reciprocal party to this transaction in a 3rd namespace
43	Customer		alternative structure for a simple customer identifier.
44	Supplier		alternative structure for a simple vendor or supplier identifier.
45	Amount	Yes	any numeric value consistent with your functional currency.
46	Currency		ISO 4217 currency code applicable to Amount
47	AmountForeign		any numeric value consistent with the currency in CurrencyForeign below
48	CurrencyForeign		ISO 4217 currency code applicable to AmountForeign
49	Description		explanation text or memo string etc.
50	AccountCode	Yes*	the chart of accounts account code for the transaction if segmented codes are not used.
51	AccountName		name of the account in chart of accounts
52	AccountSegment1	*	the 1st (leftmost) segment if segmented account code applies, for this row
53	AccountSegment2	*	the 2nd segment if segmented account code applies, for this row
54	AccountSegment3	*	the 3rd segment if segmented account code applies, for this row
55	AccountSegment4	*	the 4th segment if segmented account code applies, for this row
56	AccountSegment5	*	the 5th segment if segmented account code applies, for this row
57	XBRLtype		classification of this row for GAAP reporting.
58	XBRLtaxonomy		GAAP or other XBRL taxonomy of which the XBRLtype is a member
59	CostCenter		any accumulator supporting grouping of expenses and costs.
60	Fund		a legal or budgetary unit such as within municipal or not-for-profit ledgers
61	Project		1st level of project code
62	ProjectActivity		2nd level of project code if applicable
63	Cost		Cost of the item associated with this revenue amount.
64	Job		uniquely identifies the job, project, etc.
65	TransactionCode1		1st user defined category, class, T-code etc. (attribute of a transaction row)
66	TransactionCode2		2nd user defined category, class, T-code etc.
67	TransactionCode3		3rd user defined category, class, T-code etc.
68	TransactionCode4		4th user defined category, class, T-code etc.
69	TransactionCode5		5th user defined category, class, T-code etc.
70	TransactionCode6		6th user defined category, class, T-code etc.
71	TransactionCode7		7th user defined category, class, T-code etc.
72	TransactionCode8		8th user defined category, class, T-code etc.
73	TransactionCode9		9th user defined category, class, T-code etc.
74	TransactionCode10		10th user defined category, class, T-code etc.
75	GroupID		associates this transaction within any related set of transactions within an ebXML "Commercial Transaction Pattern" or other choreography
76	NegotiationState		Negotiation state; received, accepted, fulfilled, settled, etc.
77	DueDate		"YYYY-MM-DD" date the asset/liability is/was due
78	Settlementmethod		bank, settlement agent or method the asset/liability will be or was settled
79	SettlementDate		"YYYY-MM-DD" date the asset/liability is/was settled
80	AmountSettled		Amount of the original asset/liability that has been paid or settled
81	Cleared		0=no, 1=yes to mark this row as matched, settled, cleared, etc.
82	Voided		0=no, 1=yes to mark this row as voided or reversed.
83	MatchedReference		RowID or other reference which this entry is offset by
84	Product		Item, SKU or other unique identifier for the product or service.
85	Service		Unique identifier for the services performed, to be performed etc.
86	Quantity		Quantity of the above product or item or service.
87	UnitsOfMeasure		Units of measure in Quantity
88	InvoiceNumber		Invoice number associated with this debit or credit row
89	SONumber		Sales Order number associated with this debit or credit row
90	PONumber		Purchase order number associated with this debit or credit row
91	TimeStamp		digital timestamp
92	XMLdocument		any XML business doc. accompanying this transaction.

Transactions consist of 2 or more rows which sum to zero.  The last field (XMLdocument) is an optional string space for XML documents such as POs, Invoices, etc. Most or all of the other fields could have been stored within the XML document.  Required fields were defined natively in the table for dates, account codes and other keys to improve query performance, reduce the logic required on the client and server, and keep the data structure understandable and manageable by users not skilled in XML.  

The XMLdocument field for any given row can be of arbitrary complexity. For example, validating XML editors are expected to become as commonplace as word processors in future years.  Such applications may be used to create invoices for submission with a rootledgerXML journal entry, or, to create entire journal entries with such invoices nested within them.  

To minimize the unnecessary repetition of data within the instance documents, default values for every field required by an application may be transmitted within a single row at the top of the file with zero transaction amount.  

3. The  rootledgerXML dtd

The XML DTD is displayed below 

<!--  rootledger.dtd v0.8 draft tboyle@rosehill.net 9/6/2000 -->

<!ELEMENT Transaction  ( JELine )+>
 (((((( etc. a flat schema with no constraints)
<!ELEMENT JELine (Host, HostKey?, OriginalHost?, OriginalKey?, (snip):

Example instance of rootledgerXML:

<Transaction>
  <JELine>
   <Entity>ToddsConsultingLLC</Entity>
   <TransactionID>0000111</TransactionID>
   <TransactionRowID>0000001</TransactionRowID>
   <TransactionDate>2000-08-22</TransactionDate>
   <Reference>DepositAug17</Reference>
   <XBRLtype>accountsReceivableTradeGross</XBRLtype>
   <Party>MyClient, Inc.</Party>
   <PartyRole>Customer</PartyRole>
   <Amount>-97.50</Amount>
   <Description>3 hours site visit 13 Aug.</Description>
   <AccountCode>12000</AccountCode>
   <Project>MCI-4</Project>
  </JELine>
  <JELine>
   <Entity>ToddsConsultingLLC</Entity>
   <TransactionID>0000111</TransactionID>
   <TransactionRowID>0000002</TransactionRowID>
   <TransactionDate>2000-08-22</TransactionDate>
   <Reference>DepositAug17</Reference>
   <XBRLtype>cash</XBRLtype>
   <Party>Bank of America</Party>
   <PartyRole>SettlementProvider</PartyRole>
   <Amount>97.50</Amount>
   <Description>3 hours site visit 13 Aug.</Description>
   <AccountCode>10100</AccountCode>
   <Project>MCI-4</Project>
  </JELine>
</Transaction>

Or look at it another way. Here is all 92 fields: 

<Transaction>
   <JELine>

<Host/>
<HostKey/>
<OriginalHost/>
<OriginalKey/>
<Entity/>
<Division/>
<Department/>
<Section/>
<Country/>
<Geographic/>
<GeographicSubarea/>
<Language/>
<Journaltype/>
<TransactionID/>
<TransactionRowID/>
<TransactionRowCount/>
<TransactionDate/>
<TransactionTime/>
<TransactionTimeZone/>
<TransactionType/>
<TransactionBatchID/>
<TransactionPostDate/>
<PostedStatus/>
<Period/>
<TaxTypeCode/>
<EliminationsCode/>
<EnteredDate/>
<EnteredTime/>
<EnteredTimeZone/>
<User/>
<UserSignature/>
<Employee/>
<Approved/>
<Reviewed/>
<Reference/>
<Reference2/>
<Party/>
<PartyRole/>
<PartyContact/>
<PartySignature/>
<Party2/>
<Party3/>
<Customer/>
<Supplier/>
<Amount/>
<Currency/>
<AmountForeign/>
<CurrencyForeign/>
<Description/>
<AccountCode/>
<AccountName/>
<AccountSegment1/>
<AccountSegment2/>
<AccountSegment3/>
<AccountSegment4/>
<AccountSegment5/>
<XBRLtype/>
<XBRLtaxonomy/>
<CostCenter/>
<Fund/>
<Project/>
<ProjectActivity/>
<Cost/>
<Job/>
<TransactionCode1/>
<TransactionCode2/>
<TransactionCode3/>
<TransactionCode4/>
<TransactionCode5/>
<TransactionCode6/>
<TransactionCode7/>
<TransactionCode8/>
<TransactionCode9/>
<TransactionCode10/>
<GroupID/>
<NegotiationState/>
<DueDate/>
<Settlementmethod/>
<SettlementDate/>
<AmountSettled/>
<Cleared/>
<Voided/>
<MatchedReference/>
<Product/>
<Service/>
<Quantity/>
<UnitsOfMeasure/>
<InvoiceNumber/>
<SONumber/>
<PONumber/>
<TimeStamp/>
<XMLdocument/>

   </JELine>
</Transaction>

It is suggested that this schema is an appropriate foundation for A2A (application to application) integration between any externally hosted business application and the master general ledger (root ledger) of the entity who owns the transactions.  

The rootledgerXML schema was designed as a flat, single-dimension to take it as far as possible down the spectrum so that every little GL in the country having an ASCII interface can integrate with it. Any programmer of moderate skill would be able to convert to and from flatfile data formats, such as comma delimited files, to conduct business over the internet with this schema. 

XML files in rootledgerXML format can be imported almost directly into Peachtree and a number of other ledgers, because it is a flat XML schema. Conversion from a flat XML file into a Peachtree comma delimited file can be done as simply as a macro in Excel. It is almost as simple as searching and replacing tags with quotes and commas.

The question whether an XML standard for General Ledger should be a flat schema or a hierarchic one is not theoretically important. Because the problem domain for accounting entries has certain characteristics, i.e. consisting of native row structure, accounting entries can be translated back and forth by a large number of applications, including XSLT. For a collection of XSLT translations between hierarchic and flat schemas, see http://www.gldialtone.com/stupidTricksWithXSLT.htm

We all know that business transactions are sometimes represented in a flat schema, and sometimes in a complex hierarchic schema.  A hierarchic schema tends to require more expensive software, and software which requires more frequent updates.

For interoperability, however one fact predominates.  If you want a universal schema, in a universe where there are any flat file GLs or storages then, you have a real problem deciding what elements to put on the header level of your proposed "standard".   What if some user happens to maintain that particular information on their rows, and has unique values in the rows?  Then, they cannot convert to your header-rows schema without loss of information.

It is logically correct that every hierarchic GL can be transformed to a flat GL by duplicating the data in headers to each detail row. But you cannot transform a flat GL instance to a two-tier GL instance.

Normalization of data structures has anyways been a hammer for anything that looks like a nail, for over 30 years.  One result has been a complex ERP software model and proliferation of data structures that are not optimal for search and query speed.  SQL-2 was significantly upgraded to SQL-99 by IETF.ref ref  ref ref   RootledgerXML is implemented harmoniously alongside ERP as well as among BSPs on the internet, providing the fact table within a star or snowflake schema for data warehouse applications. The flat General Ledger structure is also well suited for OLTP within small and midrange accounting systems.  OK here is a fact table within a star schema:

Problems

The rootledgerXML schema encapsulates GL data but has no features to invoke any functions on the destination system.  As such, its immediate usefulness is for manual exchanges, or a one-step submission "conversation".  Any rootledgerXML data may be submitted to a destination system, rendered visually with XSLT for review, or reviewed as an unposted transaction batch by users of an accounting system, for example, before posting by them.

The use of rootledgerXML in automated exchanges would require some type of solution to manage the delivery between systems, provide logging and troubleshooting, assured delivery, certain aspects of security and authentication etc.  Following are two solutions

1. Middleware or message servers at both ends, and/or
2. Substantial application logic at both ends, such as JMS or ebXML Messaging, in conjunction with an additional set of XML schemas for control messages indicating is an edit, update, or delete, and to confirm receipt etc. 

These issues are outside the scope of rootledgerXML schema.  This schema is intended as a document model for import and export of batches of arbitrary size, between legacy  general ledgers and the future of webledgers.  The import and export interfaces to the existing GLs are unique and proprietary where they exist at all.  A trail will need to be blazed for each of these platforms, using this flat structure.

Todd Boyle Kirkland WA  425-827-3107
(More discussion at GLschema1,  GLschema2, GLschemaDraft1, DraftComment1, DraftComment2)  

This was written in 1999.  I have edited it Feb 2002 to remove some of the worst errors, based on what I've learned in the last two years working in the software industry.  A flat GL schema (without child elements, having only system data types) cannot meet all of the requirements of all stakeholders in a global, public semantic model, for reasons described in GL Ontology paper.   The GLIEs model will allow the requirements of the RootledgerXML to be met, including the STR.  Please regard this document as deprecated.  See instead, http://www.arapXML.net

more stuff like this:  

http://www.arapxml.net 

http://www.gldialtone.com/STR.htm 

http://www.gldialtone.com/hypercub.htm 
http://www.gldialtone.com/datamart.htm  
http://www.gldialtone.com/dimensions.htm