Tag Archives: software vendor

14 Things to Know About ACA Software

If you are a large employer or employee benefit broker, chances are you have spent a lot of time trying to determine the best ACA 6056 reporting and compliance solution. At ACA Reporting Service, we do not sell software – rather, full-service reporting. However, we have researched almost a dozen different Affordable Care Act employer reporting and compliance vendors, and we thought we would pass along what we learned.

Beginning Questions to Ask Yourself

As an employer or benefit broker, this is how the ACA software question breaks down for you.

1). Some employers will have their online enrollment (benefits administration) and payroll with the same vendor. In those cases, as long as the client is willing to pay for it, it will likely to make sense to just perform this required ACA reporting of IRS forms 1094 and 1095 with that vendor.

2). Some employers will not have an outside benefits administration vendor or payroll. They do everything in-house. For these employers, there is going to be a lot of ACA work to be done, and obviously you will need a stand-alone solution.

3). Finally, you have some employers that have payroll and benefits administration with different vendors. This would include the scenario where one of these functions is performed in-house. In these cases, you will either need to consolidate both payroll and benefit plan elections with one vendor, or you will need a stand-alone solution.

Basic conclusion: If you are an employee benefit broker with various types of employer clients, we don’t see a scenario where you can get away without having a stand-alone ACA software solution to help your clients meet their 6056 Affordable Care Act employer reporting requirements.

What do you need to know in evaluating ACA stand-alone software vendors? Here are some questions to ask yourself:

1). Security? What if all the Social Security numbers of your client’s employees were stolen? Can you imagine the fallout? Many of the systems we reviewed were severely lacking in terms of security. What level of encryption is being used for the data?

2). Branded to your company? Many different ACA reporting vendors offer the ability to brand a portal to your company and let your employer clients log in.

3). Is the system mainly a benefits administration system? This can make an extreme difference. Will this add costs for the ACA reporting module? Also, with many benefits administration systems, there are additional charges for EDI (electronic data interface – where election data is sent to insurance carriers). Will additional fees apply with this new ACA reporting?

4). Is the ACA reporting solution even built yet? Many, MANY of the ACA reporting module demos we sat in on were from vendors that do not even have the software built yet.

5). How long will your data be stored? The IRS has said that audits will begin starting in about 18 months of filings, and that can last for 7 years total. If you do not have a methodology to get back to your data at the time of inquiry, you are stuck.

6). Is your vendor set up to file with the IRS? Did they just lie to you and say yes to that question? As of the writing of this blog, no one is set up to file with the IRS electronically (efile) for forms 1094 and 1095. The IRS has literally just issued the guidelines to begin getting started with this.

7). Variable hour tracking? Do you need variable hour tracking to determine eligibility? For many employers, a simple spreadsheet will do the trick. Many vendors have quite robust capabilities in this area, and for some employers this will definitely make sense.

8). The “Gotcha Moment.” This comes at the end of a great presentation when you’re told there is an additional charge of $3 to $5 per employee to file the forms with the IRS. Generally, these costs will render noncompetitive whatever solution you were just shown.

9). Robust ACA logic? We cannot tell you how important this is! If you have spent as much time looking at these forms as we have (especially in terms of form 1095c lines 14, 15 and 16), you will know that performing this reporting is MUCH MORE than just uploading a spreadsheet. The codes for these lines are based on logic. Most systems do not have this logic built into their system, so it will be up to you as an employer or benefit broker to figure this out. For most employee benefit agencies, you can count on this little “bug” shutting down your operations in January.

What if you decide to just file them incorrectly? When your largest client has 100 employees bring them letters from the IRS, you will then realize this was a very bad idea.

Also, without robust logic built into the system, there will be no accommodation for situations such as someone terminating in November/December and then electing COBRA in January. The codes for these situations are different.

10). Are forms stored for future access and corrections? Bottom line – there are going to be issues with the reporting from time to time. Do you have the ability to go back into the system and create a new/corrected 1094 or 1095 form on behalf of the employee? Many systems that rely solely on a census upload would require you to basically start over to make this one fix. OR, your staff can just manually create one in .pdf, which will take a lot of time.

11). Do you have to pay for the whole system up front, or are there monthly options? Do you need to commit to multiple years with the software vendor? Do you have to pay continually for the solution or only once? Are there implementation costs? Are there separate fees for the IRS form file reporting and all other functions in the system?

12). Can the employee elections be uploaded via census, or do you need to type it all in?

13). Will the vendor have adequate customer support between Jan. 1 and Jan. 31 so that you can KNOW you will be able to get all the work done?

14). Do you want to just let the payroll vendor do the work for your client? Do you really want to recommend that your client have another function performed by someone who wants nothing more than to take your business away from you?

. . . OK, that is enough! We hope you find this helpful.

Insurance And Manufacturing: Lessons In Software, Systems, And Supply Chains

Recently, my boss Steve and I were talking about his early career days with one of those Big 8, then Big 6, then Big 5, then Big 4 intergalactic consulting firms. Steve came out of college with an engineering degree, so it was natural to start in the manufacturing industry. Learning about bills of material, routings, design engineering, CAD/CAM … “Ah yes,” he recalled, “Those were heady days.” And all those vendor-packaged manufacturing ERP systems that were starting to take the market by storm.

Eventually Steve found his way into the insurance industry, and thus began our discussion. One of the first things that struck Steve was the lack of standard software packages in the insurance industry. I don’t mean the lack of software vendors — there are plenty of those. Seemingly, though, each software solution was a one-off. Or custom. Or some hybrid combination. “Why?” we wondered.

The reasons, as we now know, were primarily reflected in an overall industry mindset:

  • A “but we are unique!” attitude was pervasive. Companies were convinced that if they all used the same software, there would be little to differentiate themselves from one another.
  • There was also an accepted industrywide, one-off approach. Conversations went something like this: “XYZ is our vendor. We really don’t like them. Taking new versions just about kills us. We don’t know why we even pay for maintenance, but we do.”

But the chief reason for a lack of standard software was the inability to separate product from process. What does this mean?

Well, you can certainly envision that your auto product in Minnesota is handled differently than your homeowners’ product in California. I’m not referring to just the obvious elements (limits, deductibles, rating attributes), but also the steps required for underwriting, renewal, and cancellation. Separation of product from process must go beyond the obvious rate/rule/form variations to also encompass internal business and external compliance process variations.

But there’s still plenty of processing — the heavy lifting of transaction processing — that’s the same and does not vary. For example, out-of-sequence endorsement processing is not something that makes a company unique and therefore would not require a custom solution.

Where the rubber meets the road, and where vendor packages have really improved their architecture over the last several years, is by providing the capability in their policy admin systems for companies to “drop” very specific product information, along with associated variations, into a very generic transaction system.

Once product “components” (digitized) are separated from the insurance processing engine, and once companies have a formal way to define them (standard language), they can truly start making their products “unique” with reuse and mass customization. Much like those manufacturing bills of material and routings looked to Steve way back when.

This separation of policy from product has been a key breakthrough in insurance software. So what is an insurance product, at least in respect to systems automation?

From Muddled To Modeled
The typical scenario to avoid goes something like this:

  • The business people pore over their filings and manuals and say, “This is the product we sell and issue.”
  • The IT people pore over program code and say, “That’s the product we have automated.”
  • The business people write a lot of text in their word processing documents. They find a business analyst to translate it into something more structured, but still text.
  • The business analyst finds a designer to make the leap from business text to IT data structures and object diagrams.
  • The designer then finds a programmer to turn that into code.

One version of the truth? More like two ships passing, and it’s more common than you may think. How can organizations expect success when the product development process is not aligned? Without alignment, how can organizations expect market and compliance responsiveness?

What’s the alternative? It revolves around an insurance “product model.” Much like general, industry-standard data models and object models, a product model uses a precise set of symbols and language to define insurance product rates, rules, and forms — the static or structural parts of an insurance product. In addition, the product model must also define the actions that are allowed to be taken with the policy during the life of the contract — the dynamic or behavioral aspect of the product model. So for example, on a commercial auto product in California, the model will direct the user to attach a particular form (structure) for new business issuance only (actions).

Anyone familiar with object and data modeling knows there are well-defined standards for these all-purpose models. For insurance product modeling, at least currently, such standards are more proprietary, such as IBM’s and Camilion’s models, and of course there are others. It is interesting to note that ACORD now has under its auspices the Product Schema as the result of IBM’s donation of aspects of IAA. Might this lead to more industry standardization?

With product modeling as an enabler, there’s yet another key element to address. Yes, that would be the product modelers — the people responsible for making it work. Product modeling gives us the lexicon or taxonomy to do product development work, but who should perform that work? IT designers with sound business knowledge? Business people with analytical skills? Yes and yes. We must finally drop the history of disconnects where one side of the house fails to understand the other.

With a foundation of product modeling and product modelers in place, we can move to a more agile or lean product life cycle management approach — cross-functional teams versus narrow, specialized skills; ongoing team continuity versus ad hoc departmental members; frequent, incremental product improvements versus slow, infrequent, big product replacements.

It all sounds good, but what about the product source supplier — the bureaus?

Supply Chain: The Kinks In Your Links
Here is where the comparison between insurance and manufacturing takes a sharp turn. In their pursuit of quality and just-in-time delivery, manufacturers can make demands on their supply chain vendors. Insurance companies, on the other hand, are at the mercy of the bureaus. ISO, NCCI, and AAIS all develop rates, rules, and forms, of course. They then deliver these updates to their member subscribers via paper manuals or electronically via text.

From there the fun really begins. Insurance companies must log the info, determine which of their products and territories are impacted, compare the updates to what they already have implemented and filed, conduct marketing and business reviews, and hopefully and eventually, implement at least some of those updates.

Recent studies by Novarica and SMA indicate there are approximately 3,000 to 4,000 changes per year in commercial lines alone. The labor cost to implement just one ISO circular with a form change and a rate change is estimated to be $135,000, with the majority of costs in the analysis and system update steps.

There has got to be a better way …

ISO at least has taken a step in right direction with the availability of its Electronic Rating Content. In either Excel or XML format, ISO interprets its own content to specify such constructs as premium calculations (e.g., defined order of calculation, rounding rules), form attachment logic (for conditional forms), and stat code assignment logic (to support the full plan).

A step in the right direction, no doubt. But what if ISO used a standard mechanism and format to do this? ACORD now has under its control the ACORD Product Schema. This is part of IBM’s fairly recent IAA donation. It provides us a standard way to represent the insurance product and a standard way to integrate with policy admin systems. What if ISO and the other key providers in the product supply chain started it all off this way?

Dream on, you say? While you may not have the clout to demand that the bureaus change today, you do pay membership fees, and collectively the members have a voice in encouraging ongoing improvements in the insurance “supply chain.”

In the meantime, the goal to be lean and agile with product life cycle management continues. We must respond quickly and cost-effectively to market opportunities, policyholder feedback, and regulatory requirements. That all starts at the product source … but it doesn’t end there. So while the supply chain improves its quality and delivery, insurance companies will need to gain efficiencies throughout every corner of their organizations in order to achieve those lean goals.

In writing this article, David collaborated with his boss Steve Kronsnoble. Steve is a senior manager at Wipfli and an expert in the development, integration, and management of information technology. He has more than 25 years of systems implementation experience with both custom-developed and packaged software using a variety of underlying technologies. Prior to Wipfli, Steve worked for a major insurance company and leverages that experience to better serve his clients.