Start a new topic

Single Database vs. Multi Database

Leveraging R365 for your Franchisees can provide full transparency into your Franchisor/Franchisee partnerships.


Having all your locations in a single R365 database provides many benefits:


1.  Consolidated Financial Reporting and Billing

2.  Control over Purchasing and Inventory Databases

3.  Control over Product Mix

4.  Healthy Competition amongst Franchisees with the P&L Comparison Report

5.  Central Repository for Franchise Documentation and Communication


Allowing each Franchisee to maintain their own R365 database removes this transparency, however the burden of maintaining the database now falls on the Franchisee and is no longer the responsibility of the Franchisor.  


That being said maintaining the R365 accounting/operations database is typically associated with a monthly technology fee that is passed onto the franchisee and provides additional revenue.


While we lose insights into the Franchisee's financial health and purchasing we are able to maintain polling of the POS to monitor sales and product mix.  However if each Franchisee has a unique POS database then the responsibility for mapping the sales and payment types for the Franchise module billing will fall on the Franchisor.  We now have the ability to pull only the Net Sales which negates the need for any mapping, but we lose check level detail and therefore product mix in this scenario.


Ideally we want an Enterprise POS solution in place and a single R365 database for a truly scalable Franchise model.


2 people have this question

While there could be potential be admin costs for database maintenance in a single DB; I would argue that would go towards making using the modules easier as setup would fall on the gatekeeper.


For our larger Franchise groups they have implemented a Franchisee enablement program for R365 - more of a train the trainer approach.


For multi DB setups we can import the POS data to the main Franchisor database for benchmarking - this includes, pmix and labor.


I do not recommend running financial record systems in parallel and the POS import will give the Franchisor transparency into the Franchisees weekly sales.


Hi Marc,


Fantastic explanation and thank you.  I fully understand the need for only a few folks on the Franchisor side to have full admin access to any Global Records, especially if you want to ensure consistent naming standards for products, vendors, primary Accounts in the CoA, etc.


I also now understand that the Franchise module simply allows the ability to poll all franchisee POS data for sales reporting and Royalty/Marketing Fund Fee calculations.  That makes perfect sense, and somehow you've finally made that all click.


So it seems that the rest of the decision process on which route to take goes something like this:


A franchisor with a single DB can not only run and grow the overall system more effectively because of better reporting down to not just sales but profit but should be able to offer franchisees additional benefits they wouldn't otherwise receive, such as benchmarking, identifying variances from expectations on more P&L/Balance Sheet lines that might be an early signal of issues at a location, and a centralized way to monitor and enforce things like nationally contracted vendor pricing that can be corrected with better frequency and efficiency. All of these things would logically be attractive to franchisees.


However, there are some downsides to a single DB.  There will be mandatory additional admin costs for the franchisor passed along as technology fees. All franchisees may not equally want or be able to handle the costs, learning curve, or work required to use all R365 modules, meaning someone that wants to use Inventory and Scheduling with the Financial module will be more challenged to do it if most of the rest of the system is only using 1-2 modules. And most importantly, franchisees will need to relinquish quite a bit of control over their own data - no sub-accounts, more admin to set up and maintain specific products unique to a location, and having to live with their official corporate system not being under their admin rights.


Am I missing any pros/cons or either the single or multi-DB option?


It feels like a franchisor would need to gain a lot of trust from its franchisees to implement a single DB, and to communicate very effectively. Even if legal under a Franchise Agreement, does a single-DB work well without first getting franchisee understanding and support?


Also, I'm still imagining that as a system matures and grows into having many large or multi-unit franchisees, that at some point those larger ones will naturally prefer to own their own data, while other smaller franchisees don't want the admin involved in their own DB and also benefit highly from things like centralized price monitoring and benchmarking. How is that handled? Is it all-or-nothing as far as a single-DB setup, or could, say, a 20-unit franchisee do their own DB while still getting important data back into the franchisor's single-DB?  Perhaps I'm overthinking it, 


Last question (if you're still reading - this is an important topic for many and this forum is great for real-world examples of how others have thought through the issues) - we have some franchisees whose accountants/bookkeepers say simply that they cannot agree to the accuracy of their work and of the actual financials if they are required to do that work in a system of record that someone else has administrative rights to (e.g. like an R365 single DB licensed by a franchisor).  Is that reasonable, and if so, is there a way around the issue like allowing the franchisee to keep their own books but to require a weekly/monthly upload of their transactions into the R365 DB?


Thanks again for your help, and I wish I could buy you a beer for your top-notch consulting on the topic.  Let me know if you've got an hourly rate, or feel free to send me your Venmo so I can "virtually" pay for your beer.  :)

The Franchise module is solely designed for Franchisors to automate the billing of their Franchisee's by puling in daily sales and creating the calculation tables for the franchise fees in order to automate the AR invoicing.  Whether we do a single DB or multi DB we are able to poll the Franchisees POS data to achieve this.


The main benefit of a single DB, as you stated, is consolidated reporting and benchmarking of Operational KPIs across the entire concept(s).  But since we are also the accounting platform we can compare things like purchasing and pricing across the units allowing for more leverage with your vendors.


As for the user permissions and security roles there is no single simple answer.  It will ultimately come down to the legal agreements in place between franchisor and franchisee.


In all our single DB setups we see the Franchisor as the gatekeeper for all things R365, thus licensing the product to the Franchisee and including this fee in the Franchise billing. This does not mean the Franchisee does not have Full Access to their location with all it's financial and operational data.  But it does mean that admin level privileges that would allow the creation, editing and deletion of any global records are reserved for that gatekeeper.  


These global items include things like the chart of accounts and the inventory item database which are shared by all locations.  Allowing more than handful of people access to database maintenance is a recipe for disaster.  We already see this across multiple Franchisee's each with their own POS database which results in a Prodcut Mix containing CHEESEBURGER, Cheseburger, CHSBURG, when there really should only be a 'Cheeseburger' to begin with!


We have enough secondary user security roles to accommodate all levels of access so each user can fine tune the platform to exactly what they need, but even in our restaurant single and multi-unit DBs only one or two people ever have admin access to the database.


The first rule of a database is garbage in/garbage out so we want to product the integrity of the data as much as possible while still providing transparency for the users that need it.

Hi Marc,


I'm a franchisee very anxious to dive into some of the things R365 offers.  Thanks for outlining the pros and cons of a Single vs. Multi Database, it's very helpful and fills in a lot of "missing pieces of the mosaic".


I'd greatly appreciate your (or anyone else on the forum's) perspective on an issue that's come up for me and a few other franchisees.


Our franchisor is moving to R365 and is clearly intending to move to a Single Database implementation with a requirement for all locations to be under their license.  However, the communication of benefits vs. Multi-DB could be better, resulting in a scramble for more understanding of the Franchise Module.


So our issue- as a multi-unit Franchisee with my own accountant/bookkeeper, I feel the need to own the license to whatever software I'm using for my corporate System of Record.  That is, I'm not comfortable having my company books on an R365 database that I don't have full and complete admin rights to.


I not only support the desire by the franchisor to have an efficient system for things like royalty billing, etc. that they need, but I'd also be an enthusiastic evangelist for things like being able to benchmark between franchisee locations. On the other hand, due to the way our implementation appears to be planned, in the event of any future conflicts between a franchisor and franchisee in the system, a franchisee could wake up and find their logins to R365 cut off without their permission thereby losing access to their current and historical financials.  


I cannot tell if the way the implementation is planned is faulty, or if there are additional benefits to a single DB that have not been communicated, or if there's some other compelling reason for the franchisor's insistence on one way over the other.


But I cannot imagine we're the first system to face this issue.


How do systems that have, say 50+ unit franchisees operate? Are those large franchisees really keeping their system of record on a DB that the franchisor owns and controls, or is the franchisor keeping what is essentially a shadow set of financials they've been supplied in their single R365 DB, or is this a non-issue solved by how roles and rights are assigned to franchisee locations which haven't been adequately communicated?


Apologies in advance if this is an uninformed question, but it's been challenging to find more information on this topic, and your post here in this forum stood out as being from someone who might be able to explain it in an understandable way.  Thanks.

We have Franchisors with Franchisees in their databases ranging from 2 - 60 plus locations.  Since the security is tied to the location assignment on the user roles there are no concerns with security.  Additionally we have added Limited Accounting roles specific to Franchisees who want to do their own accounting within R365.


Onboarding your Franchisees to your existing database is fairly straight forward, just like adding a new location of your own.  Keeping in mind that you will be billed for these locations and passing the cost onto your Franchisee.





How many locations does your company have and have you encountered any security issues? My company wants to take this approach and are being told it can't be done as they would have to delete our historical DSS and EDI with our food vendor. We are currently using R365 for the corporate entity and want to have our franchisees to start using it in 2021. Any insights are appreciated. Thanks

The biggest challenge is allocating Franchisor resources to maintain and manage the database.  The Franchisor needs to assume the role of gatekeeper for the R365 database and not all Franchise groups have the bandwidth for this.  But adding the cost of an R365 admin to the Franchisee billing can help offset the labor costs associated with managing and supporting the Franchisees.

Thanks Marc-


What are the difficulties you have seen with having Franchise locations included in a single database?

Login or Signup to post a comment