Digital Financial Reporting

M2M (machine to machine) is defined well by Numerx as:

M2M communications employs a device (e.g., sensor, meter, etc.) to capture an "event" (e.g., temperature, inventory level, location, environment status, etc.), which is relayed through a network (e.g., wireless, wired or hybrid) to an application (software program), translating the captured event into usable information (e.g., there is a breach, corrosion requires attention, items need to be restocked, an accident has occurred, etc.)

Familiar companies such as Sprint, AT&T, Verizon, IBM; and other lesser known companies such as Numerx  and Axeda push M2M. By at least one prediction, trillions of machines are just waiting to join the M2M party.

Even Google seems to be getting into M2M.  This article has a section titled Will Google Flush M2M Down the Crapper?. This section of the article below mentions some things which might bring to mind statements you have heard when people talk about XBRL:

"It's going to raise the awareness of M2M. When executives in the board room say 'I see Google connected a smartphone to a dishwasher, why can't we connect to our equipment or our products?' it's going to raise the visibility of what you can do.

"What Google is going to find out is that connecting is pretty hard, a lot of devices aren't serving data that's usable. There is a need for a layer that turns the raw available data into usable data like temperatures, etc. into a data model that programmers can use.

"That's our secret sauce, our unique value proposition: our technology converts raw data into business data.

"It comes in obscure message format packets, with headers etc. we've got a whole set of parsers and translators that turn that into an asset, temperature. We have a rules engine that allows you to create notifications, web services layer available by REST, can do mashups with HTML or javascript."

So what does connecting a smartphone to a dishwasher or having SIRI start your car have to do with XBRL?  In a word: lots.

Millions and millions, if not billions, of business reports are shared within and among businesses and governments. Those business reports are packets of information. Maybe they are a little more complex than M2M communications, but basically it is the same idea.

XBRL is part of what will enable business-to-business, business-to-government, and government-to-government digital business information exchange.

Most of the traction XBRL has been able to create thus far is business-to-government information exchange such as banks reporting to a regulator such as the FDIC or one of the 27 CEBS supervisors, public companies reporting to the SEC or a stock exchange, corporate tax reporting to HMRC or National Tax Agency of Japan, or Standard Business Reporting (SBR) type projects in the Netherlands and Australia. Those are only some examples.

But what about some of these use cases:

• I used to work for a lumber manufacturer. As you can imagine the manufacture used a lot of equipment in the process of cutting lumber to spec; resaws, dry kilns, plainer, etc.  What if the equipment could "talk" to the accounting system, publishing the production statistics which I had to enter manually for each of those machines each day.  What if the accounting system could then send that to each manager's cell phone like real time stock information or the weather is provided today. Basically, what if you could inexpensively create your own real-time information feed?
• I used to work for a produce broker.  We had a vacuum cooler which brought the temperature of the lettuce from field temperature down to storage temperature. A person had to man that machine and occasionally they would loose their focus and a $10,000 load of lettuce would be rendered unusable because the operator neglected to do his duties.   What if the vacuum cooler could send alerts to the operator if a setting went out of bounds. Basically, what if you could create your own real-time monitoring system inexpensively?
• A friend of mine is a chiropractor.  She got a new practice management system and she loves the daily reports which the system spits out.  The receptionist prints the reports generated by the system, reorganizes them, and then emails a PDF with this management information to my friend so she can keep tabs on her business.  What if that entire process could be automated or if other additional useful reports could be sent, without the receptionist or other person getting involved in the process, totally automating the report distribution process?
• I heard a story on NPR about how schools spend a lot of money on electricity.  Leaving the football or soccer field lights on when no one is using the field is both a waste of money and a waste of a resource. Having usage patterns reported, tracked, and managed can help save money and reduce electricity use. What if you could do this for the many different devices businesses and governments use in their operations?

I could go on and on, there are plenty of these types of use cases if one really looks.

Imagine an inexpensive, easy to use, robust, reliable, error-free, scalable, secure, auditable, understandable (from a business semantics perspective); basically truly automated business-to-business, business-to-government, or government-to-government. What processes could you make better, faster, or cheaper in some way?

These processes could be within your organization or there your internal processes intersect with one of your business partners.