By: Jason Mott, Lead Software Developer

Moving large amounts of data is not easy – even with software designed to help. I understand this firsthand. For 10 years, I’ve been the lead engineer for OneReport – a web application for storing, publishing, and reporting a company’s sustainability and corporate responsibility data. During that time, the CSR space has advanced in leaps and bounds, and solutions to managing the work have had to evolve as well. We’ve witnessed not only a continual advancement of the technologies for reporting, but an ongoing evolution of the forms that reporting data takes, and ongoing redefinition of what data is material, and for what purposes.

We software engineers tend to face challenges that largely go unnoticed to those using the products we design and create. In fact, the better we do our jobs, the less likely everyone else is to know the challenges we faced. In the data collection/publishing/reporting space, these challenges are often a result of the differing needs of the various stakeholders of the data. If that weren’t enough, OneReport’s ability to address a wide array of frameworks and ratings and research organizations means that our system must be able to accommodate both diversity and precision in how it empowers clients to respond more, with less time, and in turn, have more energy to focus on sustainability performance, rather than disclosure.

As CSR continues to advance as a discipline it will become more and more important for practitioners to understand what is involved in streamlining the process of storing and moving data. Together, software developers and CSR practitioners (as well as accountants, raters, auditors, and many others) are inventing a new language for understanding value creation in business, but like any relationship, it relies on mutual understanding.

Our goal at OneReport is to make it as easy as possible for a company to store, manage, and deliver their data while keeping it secure. Our main job is to reduce what is called, “Survey Fatigue.” Collecting and entering data into a system is very time-consuming and, let’s be honest, mundane! It’s even worse if you have many different frameworks and ratings organizations to address in different systems. Managing these individually poses data management, data consistency, and institutional tracking/memory challenges.  OneReport’s design goal is to be a single point of entry and storage for corporate environmental, social, and governance data and to automate the publishing, response, and reporting process. In the last year, we’ve focused our efforts on improving our data storage methods to make the data as portable and reusable across corporate responsibility frameworks as possible, yet tailored as needed. This positions us for efficient importing and exporting to and from other systems. We have long provided the means to carry forward legacy data, along with various associated data, to simplify work. Historical data and associated resources can be leveraged from year to year with flexible updating/pre-filling options to minimize redundant entry. We are not just talking about quantitative data or data points.  Our platform was built to handle qualitative data as well, and to structure input in a logical, pre-structured way.  We also make sure that comments and supporting references can be tied to a particular set of frameworks so that data is directed to its intended audience.

One of the biggest hurdles we face is making the data portable enough to be automatically transferred into other systems (e.g., reporting to a research organization that has its own system for data entry/storage). Every system will have its own formats and validation rules and keeping up with the changes, let alone implementing it in the first place, is a monumental effort. And, the metrics themselves continue to evolve.

OneReport is designed to capture and store data in a portable way; we’re in the process of taking this to the next level to support seamless data transfers. One of the first standards we will support is XBRL, or Extensible Business Reporting Language, is an XML standard that clearly defines how to format data for delivery from one system to another. XML itself is what is called a markup language. It’s a set of character strings that begin and end data in a text file in order to provide rich information about that data. For example, we might wrap a number in some tags that let us know it’s a number, that let us know if it’s an integer (a whole number), or a floating point (whole and/or fractional number). This is called “normalized data.” In a nutshell, it means that it’s ready for a computer to read and understand it. With XBRL, it’s also human readable, which has many advantages.

Since 2005, the SEC has utilized both XML and later XBRL to facilitate structured disclosure of data for companies. Initially, use of these languages and frameworks was voluntary, but later it became required practice for some industries and reporting aspects, though none pertaining to sustainability. None the less, it is safe to assume that where the SEC leads, others will follow, and as consolidation and further definition advances, these languages will evolve into the foundation for efficient data transfer along standardized and structured lines. What a day that will be!

Data portability in the sustainability reporting space will be a lot easier once XBRL gains more steam among its stakeholders. OneReport is on the front lines of this effort. We are actively and aggressively pursuing and implementing XBRL solutions within our platform. Later this year, we will be exporting XBRL to systems that are ready to accept it. Ultimately, we will be able to import XBRL from other systems. We are already a one stop shop for sustainability data, but this will make us a one stop superstore. With OneReport, companies are able to trust the integrity of their data, it’s secure, and will remain so in transit. With XBRL, they will also be able to trust that the data will be delivered in the appropriate format for the intended destination.

If XBRL is not the appropriate solution in a given situation, that’s OK too. The portable nature of our storage design will allow us to support almost any standard, including basic spreadsheets, cloud based APIs, direct database connections, or whatever the future holds.

On the user interface side, as it turns out, there are also many advantages in working with “portable” data. It allows for flexibility in how OneReport’s data entry interface is presented to those managing the reporting process. OneReport has some really exciting changes coming in this area! Our vision is to be able to present data entry in a customized way to give a familiar context. For example, if you’re used to the organizing framework of another system, we will be able to offer custom configured views for data entry that represent other organizing frameworks. The entered data, being stored for portability, will still be there even if the organizing framework is reconfigured. The future is bright and getting brighter.