Skip to Content
AdminsJuno Spend Account

Juno Spend Account

The Juno Spend Account is a dedicated bank account for paying for all guest travel and expenses.

Like a traditional business bank account, you can move money in and out of the Juno Spend Account at any time, and funds are FDIC insured. Juno partners with Stripe Payments Company for money transmission services, with funds held at Fifth Third Bank N.A., Member FDIC.

Unlike a traditional account, every transaction is automatically categorized and enriched with travel and expense data, policy compliance data, and your configured custom fields (e.g., cost center, department).

This enables a consolidated, fully reconciled monthly statement, reducing the time required to book transactions in your accounting system.

How It Works

Onboarding

During onboarding, we collect basic compliance data to meet banking partner requirements.

Funding

Once your account is opened, transfer an initial balance into your JSA to start purchases.

Paying Vendors

As travelers make in-policy purchases and submit approved expenses, Juno pays vendors, reimburses expenses, and maintains a complete data trail.

Reconciling

Each month, you receive a fully reconciled statement for travel and expense transactions, plus a transaction-level CSV for journal entries.

Topping Up

Each month, top up your JSA via bank transfer to continue purchases and reimbursements.

Behind the Scenes: How Vendors and Guests Get Paid

For airline and hotel purchases, Juno generates single-use virtual cards for each purchase made on the Juno platform. These cards are transmitted directly to the respective vendors, so travelers don’t need to pay out of pocket for these expenses.

For Uber vouchers, your spend account will be billed directly by Uber via an ACH draw for each voucher.

For approved guest out-of-pocket expenses, Juno will handle reimbursement to your guests via their preferred method, including ACH transfers, a mailed check, and other international money movement options. Once guests have been reimbursed, Juno will debit the funds from your spend account.

Automated Reconciliation

Juno helps streamline the monthly reconciliation of your JSA purchases and expenses by automatically tracking transactions and generating unified reports. Juno tracks and reports on several types of travel-related financial data:

This page describes reconciliation for the Juno Spend Account. If your organization also pays for guest travel with credit cards, each credit card has its own per-card transaction history, CSV export, and (when Juno is the merchant of record) downloadable receipts. Credit card transactions are not included in the JSA monthly statement.

Booking Data

  • Flight reservations and changes
  • Hotel bookings and payments
  • Ground transportation (Uber vouchers)
  • Cancellations and refunds

Policy Data

  • Policy compliance flags
  • Approval details

Approval notes in invoice transaction CSVs

Invoice transaction CSVs include an Approval Notes column so you can see why an exception was approved. It contains internal notes from the linked booking or expense’s latest request only when that request is approved, either manually or automatically. Missing or blank notes, or a latest request that is pending, denied, or canceled, leave the column blank; guest-facing reasons are not substituted.

If one payout row covers multiple expenses, its cell combines the distinct notes from those expenses’ approved requests. These notes appear in the CSV export, not the invoice PDF.

Expense Data

  • Receipt uploads and AI-parsed information
  • Expense categorization and amounts

Payment Information

  • Virtual card transactions for flights and hotels
  • Ground transportation invoices
  • Traveler reimbursements

Reimbursement Currency Details

For reimbursement payout rows, the invoice PDF and transaction CSV include the original requested amount and currency, the approved expense value, and the expense-date reference conversion. They also show the amount and currency sent to the guest, the Wise rate when applicable, and the USD amount charged to your organization. Use these values together to reconcile what the guest submitted, what they received, and what your organization paid.

The USD amount charged to your organization is recorded when the reimbursement is funded, along with any applicable processing fee, and it isn’t recalculated when Juno later collects it. It’s based on what Juno actually paid out, so it can differ from the expense-date reference conversion, which is shown for comparison only.

Older payouts may not include expense-date reference rates. When that historical conversion evidence is unavailable, the report leaves those details blank instead of calculating them using a current rate.

Refund Credits in the Developer API Transactions Report

This section applies only if your organization reads transactions through the Developer API transactions report. It doesn’t change your monthly statement, transaction CSV, or dashboard views, and it doesn’t change which purchases can be refunded.

When a vendor refunds a purchase, the report shows the refund as its own transaction with positive amounts. The original charge stays in the report unchanged, so the charge and its credit together net to what your organization paid.

  • Refunds Juno passes back to you. For purchases Juno paid on a Juno virtual card, a refund appears after Juno has credited your organization — to your credit account, your card, or your Juno Spend Account — and after the original charge appears in the report. Its date is the date the vendor issued the refund. It belongs to the same booking and payment method as the original charge.
  • Refunds on your own Conferma cards. When a vendor refunds a charge it made directly to your organization’s Conferma card, the refund appears with the card issuer’s posting date and statement reference for the credit, without waiting for the original charge.

The credit amount is what your organization received. If part of a refund went back to a guest who paid a share of the booking, that share isn’t included. Refund credits don’t include a processing fee refund.

A refund might not appear in the report yet. For example, the credit to your organization might still be processing, or the original charge might not be in the report yet. These refunds appear automatically once the credit completes and the original charge is reported. Juno doesn’t guess at refunds it can’t match to one original charge, or at refunds that together exceed the original purchase amount before its processing fee (which would mean part of the fee was refunded). Those stay out of the report until they’re reviewed. If a credit is canceled after it’s reported, the reported refund stays in place and Juno reviews it.

Returned Reimbursements in the Developer API Transactions Report

This section applies only if your organization reads transactions through the Developer API transactions report. It doesn’t change your monthly statement, transaction CSV, or dashboard views.

Sometimes a reimbursement payout to a guest comes back — for example, because the guest’s bank rejected the transfer — and Juno sends a replacement payout. The expense keeps one reimbursement transaction in the report, and the returned payout doesn’t add a credit of its own.

  • Already in the report. The reimbursement keeps its original date and amounts. Once the replacement payout is paid, the payout details switch to the replacement.
  • Not in the report yet. The reimbursement appears once the replacement payout is paid.

Both happen only after Juno has undone its collection of the returned payout: reversed or credited back on your credit account, or refunded to your card in full. While a card refund is still pending, or if only part of the charge was refunded, the reimbursement stays as it is until Juno reviews it. Refunds from vendors are covered in the refund credits section above.

See Returned reimbursement payouts.

Rail in the Developer API Transactions Report

This section applies only if your organization reads transactions through the Developer API transactions report. It doesn’t change your monthly statement, transaction CSV, or dashboard views.

Charges for rail bookings, and refund credits for them, use the RAIL category. You can filter the report by parentCategory=RAIL, or by the rail booking’s ID with bookingId. Each rail transaction includes the booking ID, the confirmation number when there is one, and the departure and return dates. These are local calendar dates at the departure station. A one-way journey has no return date.

A rail transaction appears only when Juno can match a charge to one rail booking. A recorded reservation on its own doesn’t create a transaction, and a charge Juno can’t match to a booking stays out of the report. This includes a charge made before Juno recorded its booking.

Trip and Event Details in the Developer API Transactions Report

This section applies only if your organization reads transactions through the Developer API transactions report. It doesn’t change your monthly statement, transaction CSV, or dashboard views.

  • Events. A transaction’s event dates, time zone, and location are the event’s own, as currently set on the event. They aren’t the guest’s travel dates, so every transaction for an event shows the same event details.
  • Flights. The flight segments are the ones the traveler is booked to fly, in the order they depart. Flights the airline canceled or replaced with another flight are left out, as is a trip leg left with no flights, both in the segment list and the route description. If an entire booking is canceled, its charges and refunds still show the original itinerary and airline.
  • Rental cars. The merchant is the rental company from the confirmed reservation. If the confirmation doesn’t include it, the report uses the rental company chosen at booking. If neither is known, the merchant is empty.

Keeping an Integration in Sync with the Developer API Transactions Report

This section applies only if your organization reads transactions through the Developer API transactions report. It doesn’t change your monthly statement, transaction CSV, or dashboard views.

Your integration can read a single transaction by its ID to get its current values, for example after a transaction notification. It doesn’t need to re-read the whole report.

Each transaction also records when its financial details last changed, so your integration can fetch only the transactions that changed since its last sync. This includes when a transaction first appears, when its card posting is matched, when a guest payout is filled in, and when Juno corrects or voids it. Corrections and voids don’t send a notification, so syncing this way is how your integration picks them up.

Changes to descriptive details, such as traveler names, event details, custom field answers, or booking details, don’t count as a change. The report always shows their current values, so re-read a transaction when you need them. Your developers can find the details in the Developer API transactions report guide.

Held Transactions in the Developer API Transactions Report

This section applies only if your organization reads transactions through the Developer API transactions report. It doesn’t change your monthly statement, transaction CSV, or dashboard views.

Juno sometimes holds a transaction before it appears in the report — for example, while it waits for a provider to send a date or amount, or while it matches a charge to a booking. Your integration can request a summary of held transactions to check whether a charge you can see that isn’t in the report yet is one Juno knows about.

The summary shows how many transactions are held, their provisional amounts by currency, how many don’t have an amount yet, the earliest original transaction date, and how many are held for each reason: awaiting data, awaiting attribution, or under review. It doesn’t identify individual transactions. Provisional amounts can change before a transaction appears in the report.

The summary doesn’t count reimbursements whose guest hasn’t been paid yet, or spending the report doesn’t cover, such as reimbursements your organization pays from its own account. When a hold is resolved, the transaction appears in the report with its original financial date.

If a hold lasts a long time, or a charge you can see is neither in the report nor counted in the summary, contact Juno. Your developers can find the details in the Developer API transactions report guide.

Organizational Context (Custom Fields)

You have the ability to configure custom fields on your organization, which can be used to enrich the data we track. For example, many customers use custom fields to track:

  • Cost centers
  • Departments
  • Project numbers
  • Employee roles and approval levels
  • Compliance requirements (like NPI numbers)

Learn more about configuring Custom Fields here.

While Juno automates the reconciliation process, financial teams should still review reports regularly to ensure accuracy and completeness.

Last updated on