Comprehensive Fix for Accounting/Quickbooks - develop Roadmap

(page 4 )

• Page 1
• Page 2
• Page 3
• Page 4

Hi Paul,

I'm new to the Quickbooks Ownerez integration, and I have some questions.

I have turned the Airbnb transaction sync on, but I'm API integrated with Airbnb. In Ownerez, my future Airbnb bookings are shown as paid. It looks like it shows the date that Airbnb collected the payment.  Also, in my Quickbooks, the invoices show as paid ( when the quest submitted the payment, " I'm assuming)  even though I'm not getting the money until the customer checks in.  I'm doing something wrong. Please help 

Since OR doesn’t follow proper accounting practices that is the way that the software is designed to work. In the current implementation it is considered paid because the customer has paid it and when it is deposited in your bank by AirBnB it will be processed as a deposit by OR.

If GAAP accounting processes were followed those funds should be put in an “undeposited funds” asset account that would represent all the funds that AirBnB is holding on your behalf. It doesn’t help that QB doesn’t support more than on Undeposited Funds type account so one has to create other types of accounts as Undeposited Funds and if so can’t use the Deposit feature of Quickbooks.

I have requested several times that we setup a committee of users that have expertise in accounting and finance so we can create a solid roadmap for the QB integration.

The new deposits feature has been rolled out which is great to see effort but unfortunately it seems to have lack of forethought and planning from an Accounting perspective - not sure who is providing the guidance to product development but I believe that the implementation could be better. Especially for advanced users that have multiple currencies and multiple payment methods. Maybe OR core customer is the Mom and Pop so it doesn’t matter

Having said that, to do proper GAAP accounting is not a straightforward thing and there has to be a balance between practicality, QB capabilities, and Accounting accuracy and that is the reason that these trade offs should include input from a working group.

Ocean Zen, thank you for responding. I do need to follow GAAP. How would I turn off the Automatic Airbnb Payments? I can't show that I have " received money," even though I may not get the money for a year.  

I used to use BNBTally, and I did not have any of these problems. Do you have a step-by-step guide for the proper workflow between Ownerez invoices and deposits and QuickBooks? I want to make sure that my Undeposited funds/ Clearing Asset account reflects the proper balance. 

Hey Ocean Zen,

I've read your post, and I agree with you for the most part. I say "most" because there are some things that I don't understand, most likely because I don't have the accounting knowledge to parse those parts out. If you don't mind, could you please clarify some of these things for me?

...In the current implementation it is considered paid because the customer has paid it and when it is deposited in your bank by AirBnB it will be processed as a deposit by OR.

If GAAP accounting processes were followed those funds should be put in an “undeposited funds” asset account that would represent all the funds that AirBnB is holding on your behalf

Am i wrong in saying this is actually how it currently works? On my (granted, pretty simple setup) the invoice payment uses "undeposited funds" and the date on the payment is day or two (maybe) before the date when the funds hit my banking account. during normal year, not a big deal. if is going to cross to next year (i run my business on cash basis) than i will have a problem, but i do check for that manually.

"... those funds should be put in an "undeposited funds" asset account that would represent all the funds AirBnb is holding on your behalf"...i believe that is how it works right now. for me, "undeposited funds" hold all the funds for all the OTA's are holding on my behalf

It doesn’t help that QB doesn’t support more than on Undeposited Funds type account so one has to create other types of accounts as Undeposited Funds and if so can’t use the Deposit feature of Quickbooks.

This one went over my head...more than one "Undeposited Funds" type account? is that even something that QBO supports? not sure what is the use case here assuming i even understood correctly what you said

I have requested several times that we setup a committee of users that have expertise in accounting and finance so we can create a solid roadmap for the QB integration.

Yup,  i do recall that time and i completely agree with you. Not sure what is OR doing about this. I do see improvements to QBO integration, but, with all dues respect, the way those improvements work do seems to point to a lack of accounting expertise as you have pointed out many times.

The new deposits feature has been rolled out which is great to see effort but unfortunately it seems to have lack of forethought and planning from an Accounting perspective - not sure who is providing the guidance to product development but I believe that the implementation could be better. Especially for advanced users that have multiple currencies and multiple payment methods. Maybe OR core customer is the Mom and Pop so it doesn’t matter

Agree on the first part. I'm one of those "Mom and Pop" and the new deposits feature is not working for me. I'm not even sure what exactly is the use case OR thought about when they implemented this. The rest of your points here, not sure i'm parsing. i understand the words, i'm just not sure what are you referring to. (the multiple currencies and multiple payment methods part)

For me, the biggest pain point is that i need to manually match the invoice payments to banking transaction so i can add the missing expenses and run validations (check the invoice and payment dates to make sure they do not cross into next year or the other way around, adding CC charges, or AirBNB charge..so on). i was hoping the new deposit feature will help me here, but the OR gods decided (why???) to not allow me to use COGS for expenses in deposits. seriously...

Alin

BnBTally is the best accounting implementation for AirBnB (and VRBO if you are not on a PMS) that I have found. It becomes a little more complicated when you have a merchant account and are processing your own CC.

Since the deposit feature didn’t exist until now I setup my system to process similar to BnBTally syncing with Stripe and my Bank Feed. It’s not perfect as OR doesn’t open up the financial data in their API. I can try to put together a post of how I do it in the next few weeks. Would love to get better support from OR for improved accounting.

Hi Alin,

Sorry for the slow reply. see responses in line

Hey Ocean Zen,

I've read your post, and I agree with you for the most part. I say "most" because there are some things that I don't understand, most likely because I don't have the accounting knowledge to parse those parts out. If you don't mind, could you please clarify some of these things for me?

 

...In the current implementation it is considered paid because the customer has paid it and when it is deposited in your bank by AirBnB it will be processed as a deposit by OR.

If GAAP accounting processes were followed those funds should be put in an “undeposited funds” asset account that would represent all the funds that AirBnB is holding on your behalf

Am i wrong in saying this is actually how it currently works? On my (granted, pretty simple setup) the invoice payment uses "undeposited funds" and the date on the payment is day or two (maybe) before the date when the funds hit my banking account. during normal year, not a big deal. if is going to cross to next year (i run my business on cash basis) than i will have a problem, but i do check for that manually.

"... those funds should be put in an "undeposited funds" asset account that would represent all the funds AirBnb is holding on your behalf"...i believe that is how it works right now. for me, "undeposited funds" hold all the funds for all the OTA's are holding on my behalf

Yes, that is how it works if you only have AirBnB, however if you use VRBO or any other platform that requires you to use your own Credit Card processor then it becomes more complicated and you need to have more than one "Undeposited Funds" account (one for each payment processor to make reconciliation manageable). Unfortunately the single Undeposited Funds account is a QB limitation but there are work arounds and OR should pick one and support it. Another layer of complexity is Multi-Currency if you have properties in different countries. Without laying out a framework and development plan for all of these OR continue to make point or patch fixes/improvements that further lock the system into a short sighted solution that then becomes too much to work fix.

 

It doesn’t help that QB doesn’t support more than on Undeposited Funds type account so one has to create other types of accounts as Undeposited Funds and if so can’t use the Deposit feature of Quickbooks.

This one went over my head...more than one "Undeposited Funds" type account? is that even something that QBO supports? not sure what is the use case here assuming i even understood correctly what you said

See comment above - a single Undeposited Funds is a limitation from Early Quickbooks that they haven't fixed but there are ways to work around it.

I have requested several times that we setup a committee of users that have expertise in accounting and finance so we can create a solid roadmap for the QB integration.

Yup,  i do recall that time and i completely agree with you. Not sure what is OR doing about this. I do see improvements to QBO integration, but, with all dues respect, the way those improvements work do seems to point to a lack of accounting expertise as you have pointed out many times.

 

Yes, it is hard to understand when there are several users that have accounting expertise and are willing to help that they don't create a user group to address -- user groups to help with roadmap is a common practice at many software companies

 

The new deposits feature has been rolled out which is great to see effort but unfortunately it seems to have lack of forethought and planning from an Accounting perspective - not sure who is providing the guidance to product development but I believe that the implementation could be better. Especially for advanced users that have multiple currencies and multiple payment methods. Maybe OR core customer is the Mom and Pop so it doesn’t matter

Agree on the first part. I'm one of those "Mom and Pop" and the new deposits feature is not working for me. I'm not even sure what exactly is the use case OR thought about when they implemented this. The rest of your points here, not sure i'm parsing. i understand the words, i'm just not sure what are you referring to. (the multiple currencies and multiple payment methods part)

 

For me, the biggest pain point is that i need to manually match the invoice payments to banking transaction so i can add the missing expenses and run validations (check the invoice and payment dates to make sure they do not cross into next year or the other way around, adding CC charges, or AirBNB charge..so on). i was hoping the new deposit feature will help me here, but the OR gods decided (why???) to not allow me to use COGS for expenses in deposits. seriously...

 

Yes, the whole point of automation is to help with the reconciliation process... I struggle with all the above having both multi-currency and Credit Card processor account that keeps a % holdback for 60 days which makes reconciliation a nightmare

 

Alin

 

Ocean Zen,

Thanks for continuing to help other OR customers with your thoughts and advice.

For the record, we care deeply about the QB problem and, ultimately, full reconciliation.  Our latest QB Deposit update was not a patch fix, but something we planned for a long time. A lot of thought and work went into it, and it was designed to get reconciliation way further down the road (at least for certain customers), and also deal with all types of deposits - Air, Stripe, and others.

Our view of the QB integration, internally, is not about trotting out a small update every now and then just to show a token amount of progress, though I know it may seem that way.  It's been about resources and fixing other things first as prerequisites (eg. creating deposits in OR before creating deposit/fee syncing for QB).  We have already and continue to consult with accounting professionals over strategy, but our roadmap is not wholly focused on QB either, so there are resource limitations.

While we plan to add a new style of syncing (overall - a change to how revenue is recorded that doesn't use the Invoice approach), we want to continue patching the holes in the current process as there are over a thousand users that use the current process, and we want it to be accurate and work end to end.  We believe that for certain operations, the Invoice > Payment > Deposit sync method works well and should be left in place.

The next steps for us are:

• Fast follow on the deposit syncing based on immediate customer feedback (eg. removing the PM requirement for expense account settings)
• Bank accounts (ie. allow bank accounts to be defined so that money can flow correctly for PMs that deposit money to different accounts based on owner, channel, or credit card processors)
• Misc. sync holes (exchange rate setting, customer background info not syncing)
• Supporting refunds (the QB credit memo stuff does not align)
• Supporting secdeps

Outside of those things, which are all about the current syncing process, we plan to add these:

• Expense syncing (which will be similar to the existing owner payout syncing)
• Held-in-liability sync method

We have also been growing our product and engineering teams heavily over the past 12 months. That will help us keep team members focused on the fast-follows for QB that are needed to move QB down the road at a faster pace.

Paul,

Thank you for your detailed response and for sharing insights into the roadmap. Having experience in investing and running software companies, I understand the challenges of communicating roadmap details, so I genuinely appreciate the transparency you’ve provided. It’s also encouraging to hear that you’re considering broader accounting synchronization solutions beyond just QuickBooks.

That said, based on prior experiences, I hope my previous comments are seen not as criticism but as a challenge for OR to continue pushing toward leadership in this area. Customer engagement, as I’m sure you know, is a sign that people care—apathy is the real concern.

I’d like to offer some additional thoughts. OR appears to be moving from more of a consumer-focused model to something that sits between consumer and enterprise software. This transition is an opportunity to leverage User Groups, a key aspect of enterprise software development, to test and refine solutions, especially in complex areas like accounting integration.

The challenge with accounting solutions, particularly in a dynamic industry like this, is that many implementations are incomplete or poorly thought out. Given the evolution of both the industry and OR’s system, I can see why these issues arise. While it’s good to know you’ve consulted accounting professionals, prior implementations haven’t instilled much confidence. However, your current roadmap seems to reflect fresh perspectives, which is promising.

To that end, I’d suggest considering the formation of a working group with 6–10 customers who have both software and accounting expertise. Reviewing a more detailed roadmap with them before committing development resources could help prevent rework and ensure the final solution is more aligned with real-world needs.

One key area needing more clarity is how you plan to handle the differentiation between Payment Method and Payment Type in the system. Currently, linking to a QuickBooks account by payment type presents limitations, as real-world cash reconciliation often hinges on payment method (i.e., AirBnB, multiple credit card processors, and Booking.com payments). Addressing this discrepancy will be crucial for improving deposit and reconciliation functionality, particularly for operators working across multiple platforms and regions. This nuance is easily missed unless someone has firsthand experience running an STR business, which is why careful consideration of your data structure is vital.

In closing, I’d like to express my gratitude for the continued investment in the engineering team and your commitment to advancing this area of the product. I look forward to seeing how the next phase of development unfolds.

With Gratitude,

Ocean Zen