Contribution margin by venue for locker operators

For locker operators, contribution margin per location is a key KPI. It sounds simple, but it can get complicated fast when you're dealing with many disconnected systems.

I've set this up for a location-based business, and here's what worked best for me after trying different things.

1. Why build it from the GL¶

When I made customer location reports, I found that location reporting became one more thing to reconcile. What worked best for me was to have enough detail in the General Ledger itself. This becomes the source of truth, instead of Frankensteining a bunch of reports together. The General Ledger is good here for three reasons:

1. Your close procedures already reconcile and correct the entries.
2. Most transactions end up in cash, and cash is your source of truth for accuracy. Revenue, fees, payroll and card spend all hit the bank at some point, unlike accruals, which need their own support, like a contract or a schedule.
3. For accrued entries you of course need their own supporting documents.

However, this is not about getting people to be disciplined with tags and "paying more attention." It has to rely on process.

So just because something is in a reconciled GL doesn't automatically mean it's 100% correct, but with the right close checklist you can get very confident in it.

2. Define contribution margin per location¶

Contribution margin is one of the best ways to see how different locations perform with all-in costs.

• Locker rental revenue adjusted for refunds plus earned convenience fees.
• The most direct costs are fees, disputes, sponsorship or rent fees paid to the venue, and revenue share with the location.
• Next is direct labor for the people working at the location, as long as you have a clock-in and clock-out system that tracks exact hours. Then maintenance, repairs and equipment depreciation.
• It is possible to allocate overhead, but you need an allocation method that isn't made up. A bad method can make some venues look artificially good or bad.

For example, in one case we decided to split all overhead evenly by the number of venues at first. That made some very profitable venues with lower total revenue look much worse than they really were. They met the minimum revenue requirement and more than covered their expenses. They just didn't have a large share of total revenue.

A more accurate example is a regional manager's salary, split across the venues they cover. But that needs some tracking of the regional manager's time by venue.

• Some teams split this into levels: margin before overhead, then after allocated overhead (sometimes called CM1, CM2 and CM3). If you do allocate overhead, show it as a separate line, so the venue-level number stays clean.
• Write the definition down so it does not change month to month.

Trailing twelve months (TTM) is much more useful than month over month. Shorter periods have a lot of seasonality built in. Sports seasons, weather and weather-driven activities can all change a venue's profitability.

3. Set up location in the GL¶

• One location field (class, department or location, depending on the system).
• One value per venue, plus a value for corporate.
• Closed venues: make them inactive. Do not delete them.

Your GL should support location tagging. Most modern GLs do: QuickBooks, Xero, NetSuite and Kick.

If you're starting over, or not too far in with Xero or QuickBooks, I would consider starting with Kick. It's much cheaper than NetSuite, and its Claude connector can pull an account transactions report and post journal entries out of the box. The Xero and QuickBooks connectors in Claude can't pull account-level transactions yet. Another software to check out is Rillet, which markets itself around a "zero-day close."

The important part of location tagging is not setting it up in your GL. It's building a workflow that eventually automates as many of the entries as possible. If an accountant has to type in the location by hand, you can be almost certain it won't stay reliable. So use the tools you have to standardize the entry, then automate it.

4. Revenue from your card processor (Stripe or anything else)¶

• Put the location on each charge (metadata, or a product or price per venue).
• Payouts come as lump sums, so the split happens at the charge level.
• Split Stripe fees to the same location as the charge.
• Refunds and chargebacks go back to the location of the original charge.

The ideal scenario is that your custom application puts everything you need into the metadata fields: sales tax charged, any convenience fee, and the actual locker rental charge.

If the engineering team didn't set up metadata fields, I would suggest you push them to do it. They can also update the metadata on past charges, so historical transactions can be fixed too. If they still can't for whatever reason, and you don't have a data engineer or analyst on your team to help, then it's up to you, with a bit of help from Claude.

• The setup itself is too technical for this article, but here is what's needed. The core is getting your balance transaction data into a data warehouse. If your company already uses Snowflake, Stripe Data Pipeline sends data to it natively, and Snowflake is the only warehouse that gets Stripe's financial report views. The catch is that Data Pipeline is priced by the number of charges, which adds up fast when you have lots of small transactions.
• If you don't have a data engineer yet, or haven't picked a warehouse, I recommend Airbyte to BigQuery. Airbyte's Stripe connector pulls balance transactions and payouts, the setup isn't that hard, and I pay about $10 a month for it, which is more than plenty. If you use other processors, like Adyen, Square, PayPal or Braintree, check out Fivetran. It has connectors for all of them. It works for Stripe too, but in my experience it gets pricier than Airbyte.

The SQL workflow is the same either way: get the data into the warehouse, then build a set of views that transform it. For basic reporting, start with a simple view. You can add dbt later if you need it.

From there, you can push the report to Google Sheets. With the Kick connection to Claude, Claude can pull the view and post it into Kick, or build an import file for NetSuite. The important part is a deterministic script: Claude runs the same view every time instead of coming up with a new method. You can do this manually, but Claude can double-check the numbers and handle the import for you.

Why not connect Stripe straight to Claude? You can. Stripe has an official connector, and it's great for questions and spot checks, like looking up one payout or dispute. For the monthly close, I found it to be the wrong tool. Stripe returns 100 balance transactions per call, so a busy month takes hundreds of calls, and the results land in a chat instead of a table you can rerun. A warehouse view gives you the same answer every time, and an auditor can rerun it.

Once you have your deposit view, the main reconciliation is the Stripe clearing account. Payouts from the bank go into the Stripe clearing account. You know your balance is correct when the ending balance in Stripe matches the ending balance of the clearing account in your GL.

5. Revenue share and sponsorships with venue partners¶

• Revenue share: accrue it monthly by venue.
• If one sponsorship covers several venues, pick a split rule (equal, by revenue, or by days live) and keep it.

If you're dealing with location-based revenue sharing, you very likely have payouts to venue partners as part of your CM. On top of that, many venues and property owners charge a "rent fee," which they sometimes call a sponsorship. In a startup environment that can be challenging, especially with big venues. You may agree to whatever terms they set, which is understandable, but that makes the terms harder to track. Sponsorships are a straightforward accrual, or a prepaid entry if you don't pay monthly. Revenue share can be more of a challenge.

Even though your first step should be a Google Sheets calculator for each contract, once you figure out your revenue share models, standardize them in your data warehouse so the calculation is precise every time. Speaking from personal experience, a lot of venues on revenue share can get out of control very quickly.

Define the revenue base in each contract. Sometimes it's not clear where the base starts: gross revenue, revenue net of fees, revenue after all expenses, or even a trigger, like X transactions in a month. Most of my calculator issues started here.

Venues will often ask for full access to the calculations. If you have the pull, it's worth pushing your engineering team to consider setting up each venue as a Stripe connected account. But it’s a bigger project. The venue gets its own dashboard with its payments and payouts, and the split can happen on each charge. Minimums and tiers still need to be calculated outside Stripe and paid as separate transfers. It also shifts some liability. With destination charges, you stay in the business of record and pay the fees, refunds and disputes, and the platform is on the hook for negative balances on Express accounts. Either way, make sure every revenue share calculator ties back to the GL, so it's all consistent.

Depending on the contract, it may effectively be a lease. Under ASC 842, a contract contains a lease when it gives you the right to control the use of a specific asset for a period of time, in exchange for payment. For a spot at a venue, that usually comes down to two questions. Is the spot specific, meaning the venue can't move you to another spot whenever it wants? And do you control how the spot is used and get most of its benefit? If both are yes, the lease generally goes on the balance sheet as a right-of-use asset and a lease liability, based on fixed lease payments, including any minimum guarantee. Leases of 12 months or less may qualify for the short-term lease exemption.

6. Spend with Ramp¶

Regional and venue managers get Ramp cards. They tag the location on each transaction. The tag flows into the GL.

Map the Ramp tag to the GL location field. In QuickBooks Online, location can't be split across lines, so use Class for venue if one purchase covers several venues.

If a manager forgets a tag: make location a required field. Ramp sends reminders by text, email and push, and can lock the card after a deadline you set.

Switching my AP to Ramp has been a huge help. Instead of chasing people for receipts and transaction details, you crowdsource that work to the employees. Some leaders prefer to centralize card spend on American Express and then use Expensify, or even a manual expense report process. In my experience, those fall short, because you have to follow up with people manually, or two systems create more friction. You want this process to be as frictionless as possible. For controls, it's also great to have supervisors approve card transactions in real time, before they hit the GL, instead of at month-end. That also helps you move toward a zero-day close.

Ramp isn't without its issues. For example, once a transaction syncs, the GL coding and tags lock in Ramp, so any fix has to happen in the GL. But I think the benefits far outweigh the inconveniences.

A few ways we use Ramp:

• Regional managers buy supplies and order quick repairs on their own, tagged to the venue. Tight controls matter, but managers need some control over their own budget. We started with very tight controls, and it was counterproductive and created a lot of admin work. Now managers get quarterly budgets for small purchases and send a request for approval on big ones.
• Purchase requests are created with a PO before the bill arrives. Before this, POs meant either the basic PO feature in your accounting system or a separate procurement tool, which is usually pricey, complicated to set up and not a top priority for startups. Ramp makes requests easy for both managers and accounting, and it helps track the budget. Fixed asset purchases go through the same process, so each one is tagged to a location from day one.
• Reimbursements use the same location tags as card spend.
• Contracts live in the vendor profile, with reminders before they renew.

7. Payroll by location¶

Staff who work at more than one venue: hours drive the split.

This has been the biggest pain. I'm not going to get into payroll management, because that's pretty basic. But if you have maintenance or other staff who manage your locker locations, tracking how they spend their time is very important for profitability.

We tried multiple systems, including ADP and Paychex. With Paychex, we had trouble setting up GL exports by location. The numbers just weren't adding up, and we spent too much time going back and forth. We landed on a version of ADP that tracks time cards by location, by person, which is good. But it doesn't handle the actual payroll splits or the accruals, because we run biweekly payroll.

Surprisingly, there aren't many payroll tools that do this well, and none I've found so far do it 100%.

• What we set up with Claude is an upload process into BigQuery. It takes the payroll register plus the hours worked and outputs a journal entry we can import. With Claude, you can automate the import as well.
• The journal entry splits wages, employer taxes and benefits by hours, accrues the days worked after the last pay date, and ties out to the payroll register and the bank.

8. Fixed assets¶

The key with fixed assets is serializing them and, for locker banks, tracking location. It doesn't have to be fancy. It can be solved with periodic inventory checks and scanning. Many startups skip this because it can be work-intensive. It's highly recommended to either clean it up as soon as possible, or better, set it up from the beginning. Then asset allocation becomes much more straightforward.

Useful life is a management decision.

It is a judgment call, but it should be a supported one. Examples:

• Your own usage history. Bird depreciated scooters by expected lifetime rides, not years.
• Peer disclosures. Public EV charging companies use 5–7 years (ChargePoint) or 3–8 years (Blink) for chargers. Redbox used 3–5 years for its kiosks.
• The venue contract. If a unit can't be moved or reused when the contract ends, its life shouldn't run past the contract term.
• Wear and obsolescence. Hardware that goes out of date fast gets a shorter life.
• Review it every year. When Coinstar shortened the life of some kiosks, it added $2.5M of depreciation in one quarter.
• Don't just copy tax lives.

This is a bigger, but important, discussion. Most of the time I've seen useful life set arbitrarily, and I think more thought should go into it.

9. Standardize, then automate¶

I don't recommend trying to automate every little thing, unless the out-of-the-box solution already gives you everything you need. That's fine when it happens, but a lot of the time it isn't realistic, and you end up baking in procedures you didn't think through, or that haven't been hit with all the edge cases yet. Do at least a couple of runs manually before you have Claude automate everything. You need to be able to give clear instructions for the automation, not have Claude build you a black box. Everything Claude does in your close is a change to a file, turning version A into version B. It's useful to understand what those rules are, and to make sure Claude has a deterministic script to follow. That way you, or two different chats, get the same answer every time from the same information.

Things that can definitely be automated:

• Ramp imports for cards, bill pay and reimbursements. These can be set up right away.
• Stripe imports. I highly recommend fully understanding the flow of those transactions, even if you have a data or analytics person who's going to build it. It's the core revenue process, with the most transactions and the most ways to go wrong (fees, refunds, disputes, payouts).
• Payroll. You should fully understand it, but it should be automated eventually through a data warehouse. One reason to have your own finance warehouse: if there isn't enough separation of duties, you may have given someone on the engineering team access to all payroll records without meaning to. For something that sensitive, it's good to understand how to build your own warehouse, or at least understand the permissions structure.
• Kick agent review checks the basics, such as a venue tag on every transaction. It's an easy deterministic check: yes or no.
• Reconcile the clearing accounts every month: Stripe clearing, payroll clearing and Ramp. If they're off, the location split is off too. This can be automated, but you need to get the time zone and timing right so each item lands in the right period. This isn't just payroll: Stripe payouts, card settlements and bank deposits can all cross month-end.

10. Where AI helps (and where it does not)¶

Where it helps:

• Flag transactions with no venue tag, spend on a closed venue, and Stripe charges with no location.
• Suggest a venue tag from the vendor, card holder and memo. A person approves it.
• Draft variance notes by venue (labor up, minimum triggered, sponsorship ended).

Where it does not:

• The allocation rules and the split math. Those stay in formulas or the accounting system.
• Making sure contracts are read the right way. Contracts at young startups are often not written well, and you need 100% alignment with the venue on what the terms mean.
• Finding a long-running mistake. If you've been recording something wrong for a long time, AI won't notice, because it learns from your prior patterns.
• Guardrails: log what the AI changed, and keep a person on every sign-off.

Closing¶

A location P&L is only as good as the process that feeds it. Build it on the GL, and it's reconciled before anyone reads it. Standardize first, automate second, and keep a person on the sign-off. That's how locker operators that share revenue with venues know which locations actually make money.