Intuit Partner Platform team blog

Guidance on managing your customer attrition and billing

We are sharing some guidance here to make sure you don't incur unnecessary overhead fees when you have customer attrition. As a reminder, Intuit charges developers $5.00 per month for each Connect to QuickBooks (OAuth) connection made. You can read more details on that here.

Customers can stop paying for a variety of reasons including:

• Customer's payment method was declined, or just stopped paying you.
• Customer was only a trial customer and never converted to a paid customer.
• Customer legitimately cancelled their subscription to your App.

These customers have likely already successfully connected their QuickBooks data, which will result in you (the developer) being charged monthly for each of these connections. 

How can you ensure that you are only being charged for connections in which customers are paying you?

1. Make sure you utilize the Disconnect API. You should be already making this call in the disconnect link you provide in your App.
2. If you have any self-service cancel/disconnect work-flows in your app, call the above Disconnect API as part of this process.
3. On a regular interval (weekly), reconcile your paying customers against your Connections report. Then either manually disconnect each customer on the report, or create a script which  automatically batches your canceled customers, and then calls the Disconnect API to disconnect each one.

Taking the time to ensure you are following the above guidance will ensure you aren't unnecessarily utilizing services which are no longer needed.

QuickBooks API v3 April Release

Hey folks

Just wanted to give you all a quick update that the April Release for QuickBooks API v3 was completed last week. As part of that, we've published the first round of documentation and have made that available for everyone to view:

V3 docs

Currently the v3 API is only accessible by a small number of early adopters we've accepted into our v3 program. We'll open up applications again leading up to the July release. In the meanwhile if you have any comments or suggestions based on what you see in the docs, please share them here.

Registration for IPP QuickBooks API v3 Webinar

Folks,

Below you'll find the webinar registration information for our overview and update on QuickBooks API v3. Register early to reserve your spot! 

IPP Quickbooks API v3
Join us for a Webinar on February 21

Space is limited.
Reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/979269376

Please join us on Thursday, Feb 21st, at 2 PM PST as Bhavin Raval, Group Product Manager discusses the next version of Intuit Partner Platform's QuickBooks API.

Intuit Partner Platform Team
Title:    IPP Quickbooks API v3
Date:    Thursday, February 21, 2013
Time:    2:00 PM - 3:00 PM PST

After registering you will receive a confirmation email containing information about joining the Webinar.
System Requirements
PC-based attendees
Required: Windows® 7, Vista, XP or 2003 Server
Mac®-based attendees
Required: Mac OS® X 10.5 or newer
Mobile attendees
Required: iPhone®, iPad®, Android™ phone or Android tablet
  

New IPP Developer Tools - IPP API Explorer

One place to Learn, Test and Use Intuit's RESTful web APIs live!

  

Hello IPP developers,

I am happy to announce the release of the IPP API Explorer. The API explorer is an interactive interface that lets IPP Developers execute Intuit Data Services API (IDS) V2 (QuickBooks for Windows and QuickBooks Online), IDS V3 [coming soon] (QuickBooks for Windows and QucikBooks Online) and Customer Account Data API calls right from the API explorer interface. 

• Use the API explorer to learn the IPP REST APIs and test your requests.
• There's no need to spend time toggling between different interfaces or cutting and pasting. Spend less time testing your IDS requests.
• Each API/Method is listed with a complete list of available parameters.
• Input the details and with just one click, get the response in XML or JSON format.
• Sign in with you Intuit IPP credentials to store your authentication and web request details.

 

Getting Started Video: best viewed in 720p with 2x player size.

 

( Sign up for QBO, Add Customers, Sign up for IPP, Create your application, See your data in the API Explorer)

That's it, pretty simple right?

Now what?

You can explore the APIs and operations, you can see examples of each operation (create, read, update and delete). Enter in your own requests for testing and discovery, then save them for later. 

Give it a try yourself.

happy coding,

Jarred 

Intuit Developer Relations 

V3 of IPP QuickBooks API – Come along for the ride

Since arriving here last September it's been pretty clear to me that there is a certain amount of mystique and excitement associated with V3 of IPP's QuickBooks API.

Many of you have been asking for more details about the what and the when, and we recognize that we are long overdue in giving you an update.

We're finally in a solid place to invite you along for the ride and to start demystifying V3 and getting you the updated timeframes and benefits we are delivering in short order. We are actively preparing a webinar for Feb 20th at 2 pm PST – so make sure to mark your calendars.

I'll be posting the details of the webinar here over the next couple weeks. For those of you eager to get your hands on it now, we'll discuss how to apply for early access and the criteria we're looking for in early adopters for V3. Thank you for your patience and we look forward to sharing V3 with you on Feb 20th!

Grace Francisco

Sr. Manager, Developer Programs

Intuit Partner Platform to Open Financial Data Service APIs to Developers

The Intuit Partner Platform team is excited to announce that we'll be making new APIs available to Intuit’s financial data service on a limited basis in October with wider availability in December. That's right - the same services that power Quicken, QuickBooks, Mint and FinanceWorks will be available to 3rd party developers, creating new opportunities to build the next killer finance apps.

You can find out more details about this new service and sign up to receive advance release notices, invitations to upcoming webcasts and an opportunity to participate in our limited availability launch this fall.

From the official Intuit Press Release:

"Wanted! The Next Killer Finance App

Who will create the next great personal or small business finance application? And what will they invent?

Intuit hopes to answer those questions, and spur innovation, by giving third-party developers access to one of the key ingredients that has made Quicken, QuickBooks, Mint.com and FinanceWorks some of the world's most successful financial management programs. For the first time in its history, Intuit is opening the application programming interfaces, or APIs, to its financial data service in the U.S. and Canada.

By opening these APIs, Intuit is creating a unique opportunity for 3rd party developers to build new and innovative financial solutions that perhaps Intuit hasn't even thought of. This approach also supports Intuit's strategy to open its rich data ecosystem to create value for consumers and small businesses by enabling third-party contributions.

...Opening the APIs to this technology will give consumers and small businesses a broader choice of solutions to share their data with and use. Just as the Intuit Partner Platform already offers third-party developers access to QuickBooks data, this new financial data service will enable third-party technology providers to offer their customers access to their own data from more than 19,000 sources of personal and business banking, brokerage and investment accounts in the U.S and Canada."

The news is being received very well by press/bloggers, as well as the financial and technical community: Some highlights from the coverage around the web:

"What’s the next killer financial app? No one knows for sure, but the smart money is on it being built for platforms with lots of customers and many banking clients…Some of our readers might recall that Facebook kicked offs its meteoric rise by opening its API back in 2007. Intuit is betting that this invitation for third-party developers to build products based on its data management capabilities — something PayPal has already done — will produce some great products." - - BankInnovation.net

"These APIs are the key driver for what SaveUp is about…It's the cornerstone of how our product works.”- - Sammy Shreibati, co-founder and CTO of SaveUp to CIO.

"Mint has around 11 million users now, FinanceWorks (in essence a white label PFM for banks and credit unions) has over 10 million users, and Quicken and Quickbooks has a user base many multitudes above that... so this is a fantastic opportunity for fintech providers to use this data for a host of applications (or to enhance their existing offerings). Alerts, rewards, actionable notifications, loyalty programs, money movement, payment, merchant applications." - - Bradley Lemur, Mechanic Bank in comments section to TechCrunch.

"Intuit joins a growing list of companies that have opened their APIs, to varying degrees, to third-party developers. Facebook (FB) and Twitter are examples, though some companies limit access or attach other conditions. Third-party developers who use Intuit's financial data service will have access to the same data engine that powers Intuit's Mint.com, Quicken, QuickBooks Online and FinanceWorks products as well as financial data from more than 19,000 financial services organizations… Intuit shares were up nearly 1% in afternoon trading Tuesday. The stock is up 14% on the year." - - Investor’s Business Daily

--

Here's more links to the press release and other articles

• Intuit Press Release: Wanted! The Next Killer Finance App
• TechCrunch: Intuit Opens Up APIs To Financial Data Service That Powers Quicken, QuickBooks And Mint
• CIO: Intuit Opens Financial Data Service APIs to Developers
• ZDNet: Intuit opens up APIs to its financial data service in US, Canada
• Programmable Web – Today In APIs : Intuit Opens up API, Recognizing Developers, Killer Mashup Ideas and 20 New APIs

You can find out more details about this new service and sign up to receive advance release notices, invitations to upcoming webcasts and an opportunity to participate in our limited availability launch this fall.

-

Alex Barnett

Group Manager, Intuit Developer Relations

ODE to OAuth and Rest API’s and how I love thee – NOT

We always get questions about the Rest API’s and what they return versus what is returned through the SDK requests.

Well, my goal was to find an easy way to test the API’s without much trouble. To test QuickBooks desktop this was fairly easy. Just log in to workplace or your app with the appropriate company file open and in a new browser you could send the request and get a response. You could also do this with Poster and Post the body to the requested URL and you would get an answer.

Of course QuickBooks online wasn’t going to play as nice, so I had to figure out the best way to send the request. In doing so, I came across some great websites that can help make the process go smoother and help with creating OAuth signatures.

Where to begin….   Let’s get the RESTClient installed first. This is a Firefox addon that can be found at https://addons.mozilla.org/En-us/firefox/addon/restclient/. This client works well because it has the ability to add OAuth headers as well as calculating the OAuth signature when sending the request.

Once you get the RESTClient installed and running, it should look something like this:

 

Great, so now that it is installed and working, let’s move on to configuring it. This process can be used to access both QuickBooks Online (QBO) and QuickBooks Desktop (QBD) data from IDS.

1. Login to https://workplace.intuit.com and select your Intuit Anywhere (IA) application
2. Select the Development tab and make sure you have configured the QBO and/or QBD Data Source section.
3. Scroll down to the bottom section of this page and select the “Test connect to app (OAuth)” link under the Testing Your App section.

 

4. This will bring up the Intuit Anywhere Developer Playground.  Select the Connect to QuickBooks button to go through the OAuth flow for authorizing your app to have access to the QuickBooks company data. (Your Consumer Secret key will be filled in.)



5. Select QBO or QBD depending on how you configured your App above, select company and authorize.







6. Select App Menu API test from the Post-Connection Interactions section of the screen. (Your Consumer Secret key will be filled in.)



7. Now for the best part, here are your Consumer and Access Token keys and secret keys needed for signing the OAuth connections. You can also test some of the requests from this screen, but it won’t handle all the data requests, so that is the reason I am using the RESTClient addon. (Your Consumer Secret and Access Token Secret keys will be filled in.)



8. Select the RESTClient tab from earlier or if you closed it, open a new tab and start the RESTClient.
9. Select the Headers pull down and select the Custom Header. This will open a window where you will need to add the Content-Type with application/x-www-form-urlencoded as the value.



10. Select the Authentication pull down and select OAuth. This will open the OAuth window where you will put the keys from the OAuth API Console (Step 7) so that it can automatically update the OAuth signature when you make the request. When you select Insert, it will ask you if you want to automatically create a new signature each time. You should select yes. (Make sure to copy the Consumer Secret and Access Token Secret keys.)



11. You are all done. Oh, you want to see the request work. Me too. I am going to make a call to QBO services and retrieve a customer listing for my realm. The URL is the same as what you would use from the docs.  https://[baseurl]/[realm]
    1. Go here - http://oauth.googlecode.com/svn/code/javascript/example/signature.html
    2. Enter all the information requested. Yes, a majority of the values are exactly what was used in the RESTClient above except for the timestamp and nonce.  (Screen shot below.)
    3. Press the Sign button and there you go. If you captured a request from about using something like Fiddler or Firebug, you can plug in the timestamp and nonce and you should get the exact same signature as was sent from the RESTClient.

Make sure you select Response Body in the response section to see the results.



QBO Rest API’s: https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online

QBD Rest API’s: https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0500_QuickBooks_Windows

There you have it. Just make sure when are going through and authorizing the company that the URL you send in matches the company otherwise you will get an error.

Here is a way to create or verify your implementation of an OAuth signature for your request.

        



I hope this helps and enjoy.

Other consoles available, but not tested.

REST Console for Chrome: https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn

– William Lorfing – IPP Developer Relations

 

Update - October 10, 2012

It looks like the rest Client is not creating the signature correctly.

Here is how I got it to work correctly:
1. Go to http://oauth.googlecode.com/svn/code/javascript/example/signature.html and enter all the information for the signature.
2. Copy the Authorization header after you have created the signature
3. Go back to the rest client and clear the headers
4. Set the Content-type to application/xml (for create, update and delete)
5. Create a new header Authorization and past the Authorization Header from the googlecode page.

Then you can send the contents to QBO.

ProOnGo: Ushering in the Era of QuickBooks-Compatible Mobile Apps

The following is a "guest" blog post, by Phillip Leslie is Founder & CEO of ProOnGo LLC, maker of ProOnGo Expense and numerous other QuickBooks-compatible mobile apps. He can be reached at phillip at proongo.com

----

Thinking about building a mobile app that connects to QuickBooks? Welcome. There has never been a better time to do so!

Lets review. Just five years ago, of about 219M mobile subscribers in the U.S., just 9.1M of them hadever used a “downloaded application”. Today, there are far more than 9.1M new smartphones being sold-through to consumers every week, and mobile apps go hand-in-hand with unwrapping a new smartphone.  Combine that with the fact that there are 4.5M companies running QuickBooks, and you’ve got all of the ingredients for putting the power of QuickBooks into the hands of on-the-go businesspeople everywhere.  Want to be sure that the folks carrying smartphones are the same folks that want to get to QuickBooks data on-the-go?  Try looking at time-series relative search volume for the terms “QuickBooks Mobile” or “Intuit App”, and you might find yourself running, not walking, to your mobile app engineers.

Before You Do File→New Project

Before you crank out the first line of code, you might put some thought into your revenue model, because it may impact your architecture.  For this post, I’m going to assume that you have a SaaS revenue model, because that’s the clear trend amongst Intuit App Center apps in general.  At issue is the question of whether you should plan on building a mobile app that connects directly to Intuit Data Services, or whether you should build a mobile app that connects to your own web server that enables or supports the data flowing to and from Intuit Data Services.

If you decide on a SaaS revenue model, you’ll probably want the primary flow of data to pass through your own web server, rather than directly from the mobile app to Intuit Data Services.  That way it’ll be a lot easier for you to manage access rights based on business rules around your subscription packages.  I’m not saying this is the only way to architect a SaaS app, but it does seem to be the most mainstream approach.  For the purposes of this blog post, I’ll assume that you are building a mobile app that has a SaaS revenue model, and that you’ll use a custom server-side in part as a passthrough for inbound and outbound data being exchanged with Intuit Data Services.

First Things First

You are going to need some way for users to sign in.  You could homebrew your own account creation, sign in, and authentication code.  Whatever the reason, that seems to be a popular choice.  However, I’ll bet that you don’t consider your sign-in process to be the core of your differentiation, and if that’s the case I’d suggest letting someone else bear that burden.  Specifically, by relying on an Intuit Account sign-in with OpenId integration, you can rid yourself of the responsibility of building a sign-in and authentication system from scratch.

Want to know which sign-in pages Intuit has optimized for viewing on a mobile device?  Try launching your web browser with a User-Agent that urges Intuit’s web server to send you a mobile-formatted version of the page. For example, on a Mac with Google Chrome, you could open your browser window via a shortcut like:

open /Applications/Google\ Chrome.app --args -user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3"


Launching your browser with that type of User-Agent, for example, causes the App Center sign-in page to show you it’s mobile version:

 

 

 

If you’ve built any mobile apps in the past, you probably already know how to get an embedded web browser into your app (Android: WebView; BlackBerry: BrowserContent; iOS: UIWebView). You can easily point an embedded web control to Intuit’s URL, to let the mobile device’s native browser handle the rendering and user interaction of Intuit’s mobile-formatted sign-in page.

Once you’ve got a skeleton app that presents this mobile sign in page in a probably full-screen web control, you’ll need to put some thought into a strategy for doing an OpenId assertion driven by your custom web-side code, to complete the cycle of establishing a session between your mobile device and your custom server. And, you won’t have to write a lick of password storage or retrieval code. Thanks, OpenId!

Tackling the Try-Buy flow from a mobile device is an advanced topic for another time — but the above should get you going if you’ve already got a desktop-side Try-Buy flow that is the primary starting point for first-time users.

Hybrid App Basics

I’ve already urged you to hand Intuit the responsibility for maintaining the sign-in UI, and to use OpenId to cause your device<=>server session to be authenticated by Intuit. If you do all of that, then you are probably at a point where you are thinking about hiding the embedded web control upon successful sign-in, and thinking about how to transition to your native UI that exposes the main functionality of the app.

You’ve heard that hybrid apps are all the rage, and that HTML5 is making hybrid apps even more attractive, and anytime you find yourself mixing embedded web controls with native UI you are essentially building a hybrid app. So, how does a hybrid app maintain the continuity of device<=>server session when it’s initiated via an embedded web control, but later used by your app’s network connection code (like Android: HttpURLConnection; BlackBerry: HttpURLConnection; iOS: NSURLConnection)? Although there may be some oddball exceptions, the vast majority of device<=>server session management for embedded web browsers is handled via session cookies. The rules by which the session cookies are issued and invalidated end up being specific to web server, configuration, and server-side code base, but a search for the following terms will lead you to abundant information about the most popular session handling semantics: JSESSIONID, PHPSESSID, ASP.NET_SessionId, sid.

Once you nail down the nature of your web server’s Set-Cookie headers (try Firebug or Chrome Developer Tools to verify your understanding), you are well on your way to writing mobile app code to manage the hand-off of the relavent session cookies from your embedded web browser to your customized device-side network connection code.

Consuming and Sending Data

At this point, you have a user that is authenticated by Intuit, with a session established between the mobile device and your server, and we’ve made the assumption that the Try-Buy flow was handled via a desktop-side first-use experience. If you’ve made it this far, you are in a position to begin exchanging data with IDS via your server, with the sends/receives either happening synchronously when your mobile app requests it, or asynchronously to do some predictive caching of resources that you anticipate your mobile app will need frequently. If you’ve written much web service code for use from mobile devices, you’ve probably settled on a RESTful design, and my suggestion would be that the mobile<=>server interactions should pass XML bodies that conform to the IDS data models. After all, if the destination or source of the data is IDS, and if you are aiming for a seamless integration with QuickBooks, it seems undesirable to invent an intermediate XML schema for mobile<=>server interactions. If you are worried about the “heaviness” of some of the IDS-returned XML bodies, you could certainly cull the nodes that you know your mobile app won’t consume.

I’d recommend having class definitions, parsers, and serializers for the IDS objects that you rely on most heavily. Without getting into the always-heated debate of what design pattern is most appropriate, let me suggest that in basic terms you’ll want to be able to pass around IDS objects in an object type that makes sense on your mobile device.

For example, on iOS, having objects that conform to NSObject puts you within striking distance of being able to conform to additional protocols (like NSCoding) that will take some of the load off your developers when they get around to implementing local caching of IDS objects.

We’re Out of Time, But…

There is so much more to say, for example, about:

• Managing asynchronous connections to make the QuickBooks data-driven scenarios “feel” just as snappy as if they were local to the device
• Developing a caching strategy, and a method of keeping track of dirtied objects and resolving conflicts
• Using the server-side to shield your mobile device code from having to know whether the data source is QBO or QBD

…however, these and other topics will have to wait for a future post.

Phillip Leslie is Founder & CEO of ProOnGo LLC, maker of ProOnGo Expense and numerous other QuickBooks-compatible mobile apps. He can be reached at phillip at proongo.com

 

Released: Windows Azure SDK 2.0 for Intuit Anywhere

Released: Windows Azure SDK 2.0 for Intuit Anywhere

The Windows Azure SDK 2.0 for Intuit Anywhere is a set of development tools that enable developers of SaaS apps developed on Windows Azure to publish those apps on Intuit App Center, where they are available to millions of Intuit customers. 

Developers who are not on the Azure platform will still benefit from the Intuit Partner Platform .Net DevKit 2.0 and Visual Studio add-in for Visual Studio 2010 as they integrate their applications to QuickBooks data via Intuit Anywhere and .Net. 

The SDK contains the following components:

Developer Tools

• Intuit Partner Platform .Net DevKit v2.0
• Intuit Anywhere Add-in for Visual Studio 2010
• Windows Azure Templates for Intuit Anywhere

Marketing Benefits

• The Windows Azure SDK Program for Intuit Anywhere includes great marketing benefits for your SaaS app, including:

Microsoft Front Runner Program for the Intuit Partner Platform - A collaborative effort between Microsoft and Intuit

Intuit Partner Platform .Net DevKit v2.0 [Link] 

The IPP .NET DevKit has set of .NET classes that make it easier to call Intuit Data Services QuickBooks for Windows and Online. This release has full support for Intuit Anywhere. Some of the features included in this DevKit are as follows:

• Methods to call Data Services APIs synchronously or asynchronously, enabling your apps to access QuickBooks entities such as accounts, customers, invoices, and so forth.
• Ability to perform single and batch processing of CRUD operations on all QuickBooks Desktop (Windows) and QuickBooks Online entities, both synchronously and asynchronously.
• OAuth and SAML support for Federated apps.
• Reporting Service APIs for accessing QuickBooks Desktop (Windows) reports.
• Retry policy constructors to help apps handle transient errors.
• Logging mechanisms for trace, request/response, and Azure logging.
• Sync APIs that assist with data synchronization between QuickBooks Desktop (Windows) and Intuit’s cloud.
• Query filters that enable your app to retrieve QuickBooks entities whose properties meet specified criteria.
• The IPP .NET DevKit provides three different ways to log messages:
  • Trace Log
  • Request and Response Log
  • Azure Log Interface

 Intuit Anywhere Add-in for Visual Studio 2010 [Link]

• Intuit Anywhere Azure ASP.NET Template extension  
• Intuit Anywhere Azure MVC 3 Template extension  
• Drag and Drop code snippets for Intuit Anywhere Oauth, OpenId and Blue Dot components. No coding, just provide your apptoken, consumer key and secret in the config file!!

Windows Azure Templates for Intuit Anywhere [Link]

• MVC 3 Template
• .Net ASP Template

DevKit Documentation [Link]

 

 Happy Coding.

-Jarred Keneally

 

 

 

 

Live Blog from the Intuit App Showcase

We're in San Francisco today for the Intuit App Showcase and we'll be live blogging all day.  There are 30 talented developers here to pitch their apps that solve small business challenges to group of VCs.  At the end of the day, we'll award $100,000 in prize money to three winners.

Bang the gong (literally--there's a guy in a fur vest and leg warmers and a Viking hat banging a gong) the game is on!

Agile Ship has taken the stage to start the day.  They've built an impressing shipping app that saves time and money for small businesses who use QuickBooks;  the logic in the app eliminates errors and enables a business person to quickly and accurately manage end to end process of shipping. They guarantee you'll be able to ship with 10% less cost than you get on your own.  We like their bright purple t-shirts sporting the line  "Make Ship Happen."

HireFlo makes small businesses better at hiring by using the app.  If you're asking "where do I place my job notice?  How do I handle resumes?"  HireFlo might be for you.  HireFlo first publishes your job notice to Simply Hired and other free sites with a single click.  It also recommends a series of actions you might take including sharing on Linked In, Twitter and Facebook to spread the word.  The app also enables you to view a history of any interaction the candidate has had with your company.  With a few pieces of JavaScript pasted into your website, applicants can see all job openings that you have.  The next feature up is helping employers write better job specs.  Pretty cool.

Now Costavior is on stage.  Costsavior enables any company maximize profit.  This app has a nice, clear integration with QuickBooks and provides a wealth of financial information based on a company's data.  It also educates business owners on key measures are and why they are important.  This app is for business decision makers who want to play with scenarios and really understand how to improve their bottom line.

AtDuty is a field service app.  The head office can send work orders to field reps' phones with full job information.  The field service rep can quickly review the day's jobs and input start and finish times.  An electronic signature closes the job.  Writing the information back to QuickBooks closes the loop.  Sweet!

TransactionPro Importer allows you to import information like invoices and journal entries from Excel or .csv file into QuickBooks Online.  They've already had 10,000 customers using an SDK variant of the app.  You can easily map fields from an existing list or create your own fields to your import files.  This should save time and improve accuracy for business owners!

ProOnGo on stage now.  1036 expense apps in the world and we need another?  Yes!  They cover four phone families, there's an always-in-sync workflow, and full QuickBooks compatibility.  Everything you create flows to your manager's mobile device for immediate approval (or rejection).  Use your device's phone and snap an image of the receipt and that gets sent along.  The expense is quick to file and approval takes literally just a second.  All of the line item data is captured in QuickBooks.  Impressive!

Now a man in a towel has taken the stage and is covering himself with shaving cream while Vivaldi plays. He's sculpting shaving cream on his face and hair to create characachures . . . an old man, a satyr.  It's a little weird to watch this but it's fun.  A wipe of his hand and a new face emerges.  This guy is like a mime whose medium is shaving cream.  The audience seems to be enjoying it.  Now he's writing the Intuit brand across his chest to great applause.