Ramp Setup Guide: What to Do in Q360

Audience: Q360 admin and accounting leads
Purpose: Pre-work and configuration so the Ramp connection matches how Q360 works. (This is the companion to the Ramp-side setup guide and the Ramp Overview article.)
Applies to: Q360 26.05 and later
Last updated: 2026-10-21

---

Before You Begin

The guide has three phases:

1. Pre-Work — Clean up and prepare in Q360 before turning on the integration
2. Configuration — Enter settings and do the one-time push to Ramp
3. Go-Live — Test, cut over, and monitor

Complete pre-work first. Bad data in Q360 is the most common source of problems after go-live.

Already live on Ramp? If you set up the integration on a release before 26.05, see Upgrade from an Earlier Release to v26.05 at the end of this guide.

Who can manage the integration

Administrators have full access. To let a non-admin finance user run the integration, grant them the Ramp Config Maintenance Form permission through the standard permission administration screens. With it, they can open the Ramp configuration and use Test Connection, Register Service, and Register Webhooks. Changing and saving the configuration settings still requires an administrator.

In this guide:

1. Pre-Work Checklist
2. Configuration
3. Go-Live
4. Ongoing: What Happens Automatically
5. Troubleshoot Symptoms
6. Upgrade from an Earlier Release to v26.05

---

1. Pre-Work Checklist

Do this before opening Maintenance → API Config → Ramp.

1.1 Clean up expense categories

These become the coding choices employees see in Ramp. Names appear exactly as they do in Q360.

• Deactivate categories you no longer use
• Add any missing categories
• Use clear, employee-friendly names

1.2 Clean up vendors

Q360 sends vendors to Ramp based on your sync mode. They should be accurate before you push.

• Inactivate vendors you no longer use
• Check addresses — every U.S. or Canadian vendor must have a valid state or province or the push fails
• Assign an AP-Main contact to each vendor you buy from regularly
• Verify the AP-Main contact record itself has an email address populated — the contact existing is not enough; the email on the contact is what Ramp receives
• Verification: Run the Sync Vendor Report (Live Data → Report Q0404) and check the Contact Email column for blanks before pushing vendors

Ramp needs a contact email for each vendor. Q360 uses the AP-Main email first. If there is none, Q360 falls back to a default email you set in config (Step 1.9). Vendors with no email and no default will not sync.

1.3 Review the chart of accounts (GL)

During registration (Step 2.5), Q360 sends your GL list to Ramp. Clean it up first.

• Clean up descriptions — they show in Ramp exactly as written
• Deactivate GL accounts employees should not use for coding
• Confirm account types are correct
• Heading accounts are not synced to Ramp — only posting accounts are included

1.4 Employee records (for reimbursements)

For each person who will submit reimbursements in Ramp:

• They have a Q360 user account
• Their Q360 email exactly matches their Ramp email
• Their employee record has a Default Vendor — the employee vendor Q360 creates the reimbursement voucher for and pays

If an employee has no Default Vendor, their reimbursement is not imported. Sync Error History names the employee. Fix the employee setup, and the reimbursement is picked up on a later sync.

1.5 Branches and departments

These become dropdown choices in Ramp. Clean lists mean cleaner coding.

• Deactivate branches and departments that should not appear in Ramp

1.5a Call statuses (General Codes)

Calls sync to Ramp as coding options (the custom accounting field for calls). A call is only picked up if its status is one of the CALLSTATUS general codes flagged ACTIVE — codes missing the ACTIVE flag are treated as inactive and their calls will not sync.

• Open Maintenance → General Codes → CALLSTATUS and confirm every call status that should be usable has the ACTIVE flag set
• Watch for partially configured lists — during one customer setup, roughly half of the CALLSTATUS general codes were missing ACTIVE, so those calls silently did not sync. Check the full list, not just the common statuses

1.5b Customer and site addresses (states/provinces)

Just like vendors, U.S. and Canadian customers and sites must have a valid state or province on their address, or records tied to them can fail to push.

• Confirm every U.S. or Canadian customer and site has a valid state or province populated
• Confirm the States/Provinces general code list itself is populated for the countries you operate in — records referencing a missing state/province value will fail

1.6 Decide how vendors sync to Ramp

Mode	What it does
Sync All	Sends every vendor, active and inactive. Use only if your data is very clean.
Active Only	Sends only active vendors.
Report-Based	Sends only vendors returned by a Live Data report you choose. Recommended default.

Recommended: start with Report-Based. Sync All and Active Only will attempt to push every qualifying vendor automatically — if any vendor is missing an AP-Main contact and no default email is configured, the push fails for that vendor. If a default email is configured, the wrong address may reach Ramp. Report-Based forces a deliberate selection so you only push vendors that have been reviewed and are correctly set up. This is the safest starting point until you have full confidence in your vendor data.

• Pick a mode (Report-Based recommended)
• If report-based: have the report name or number ready (Live Data → Ramp Sync Vendors, Report Q0404)

1.7 Card liability GL (if you use Ramp cards)

Ramp issues corporate credit cards to employees for company purchases. When an employee uses a Ramp card, the charge is a company expense — not a personal one to be reimbursed. Ramp has already paid the merchant, so Q360 records the charge directly in the GL: it debits the expense (from the category the employee coded) and credits a card liability GL account. No voucher is created, and no vendor is needed.

• Identify or create a liability GL account (e.g. “Ramp Credit Card Liability”). To create a GL account, go to Accounting Admin → GL Admin → GL Accounts. The Bank flag must be set on this account — it functions as a bank account for card transaction clearing.
• After registration, you will confirm this account on the RAMP-PAID expense pay code (Step 2.5).

1.8 Bank and liability accounts for Ramp activity

Q360 needs the accounts below — confirm each with your controller before configuration.

Ramp AP Bank Account (bills)
Used when Ramp marks a bill as paid and Q360 records that payment. This is configured in core Q360 setup.
– GL account type: Asset — this should be your actual checking or cash account that funds leave from when Ramp pays a vendor
– If this is set up as an Expense, Revenue, or wrong Liability account, payments will post to the wrong place on your balance sheet

Reimbursement Bank Account (reimbursements)
The account reimbursement payments post from when Ramp pays an employee. It comes from the reimbursement bank account your Ramp admin assigns in Ramp (Ramp-side guide Step 4A) and appears on the Ramp config Company Map after registration.
– GL account type: Asset — the checking or cash account Ramp pays employees from
– Every company that receives reimbursements needs one. Without it, reimbursements cannot be paid in Q360.

Employee reimbursement liability
Holds what the company owes employees between the expense being recorded and the reimbursement voucher. You will confirm it on the RAMP-UNPAID expense pay code (Step 2.5).
– GL account type: Liability
– If this account does not already exist in your chart of accounts, create it before proceeding

Do not assume this is obvious. The wrong account type here will cause transactions to post incorrectly. Confirm each account and its GL type with your controller before going further. If you have set up a Payment Processor integration before, this requires the same care.

1.9 Default contact email (vendor fallback)

Recommendation: leave this blank.

Without a default email, any vendor that is missing an AP-Main contact will fail to sync with a clear error. This is the desired behavior — it makes the gap immediately visible so you can fix it (add an AP-Main contact to the vendor, then edit and re-save the vendor record to push it to Ramp). From that point, the vendor syncs on every save automatically.

Configuring a fallback email masks missing AP-Main contacts: vendors get pushed to Ramp with a generic address that may not represent them correctly, and the gap is invisible until something goes wrong downstream. Worse, if you later add the correct AP-Main contact to the vendor in Q360, that email will not update in Ramp — Ramp does not currently have an API endpoint to update vendor contact email. So the generic fallback address will persist in Ramp permanently unless manually corrected there.

If you must use a fallback (not recommended): Agree on an address (e.g. ap@yourcompany.com) and understand that any vendor without an AP-Main contact will be pushed with this address. Plan to audit and correct those vendors in Ramp after go-live.

1.10 Accounting periods

Q360 posts each Ramp item into the period of its accounting date, and records reimbursement payments in the period of the payment date.

• Keep AP and GL periods open for any dates you expect Ramp activity to land in
• Items dated in a closed period are not imported; Sync Error History says which period is closed

---

2. Configuration

Prerequisite 1: The Ramp integration must be enabled on your Q360 environment by Solutions360 before the configuration screen is available. If you do not see “Ramp” under Maintenance → API Config, contact your Solutions360 representative. After it is enabled, clear your browser cache and refresh the page.

Prerequisite 2: The Q360 API Director must be configured with the correct Ramp API endpoint URL before the connection test will work. This is typically already set, but on a fresh environment it may need to be configured by Solutions360. If the connection test returns a 401 authentication error and your credentials are correct, the API Director is the most likely cause.

Prerequisite 3: Complete the Ramp-side setup (Ramp-side guide Steps 1 and 2) before you connect. The API application’s scopes should be in place before you enter its credentials in Q360.

Open Maintenance → API Config → Ramp.

2.1 Connect to Ramp

The setup panel on the Ramp config page walks you through connecting.

• Get the Client ID and Client Secret from your Ramp admin (Ramp-side guide Step 2)
• Enter them in Step 1: Connect to Ramp and click Save Credentials
• Q360 saves the credentials, tests the connection, and registers webhooks — each step shows its result as it runs. Webhooks allow Ramp to notify Q360 in real time when transactions are approved, bills are paid, etc., rather than waiting for the next polling interval.
• Check the Access Enabled checkbox if it is not already checked

If a step fails, the message names the step and the reason. Fix the issue and click Save Credentials again — re-running is safe and does not create duplicate webhooks. The Test Connection and Register Webhooks buttons remain available if you need to re-run either step on its own.

2.2 Map companies to Ramp (one-to-one)

Each Q360 company must link to exactly one Ramp entity. You cannot share a Ramp entity across two Q360 companies.

• For each Q360 company, select the matching Ramp entity
• Confirm no Ramp entity is used twice

Activity from an unmapped Ramp entity will not import. It appears in Sync Error History so nothing is lost silently.

2.3 Enter integration settings and save

Fill in the settings on the settings screen, then click Save:

• Default contact email — leave blank (recommended). See Step 1.9. Only fill this if you have a specific reason to use a fallback address.
• Vendor sync mode — set to Report-Based (recommended); if report-based, also enter the report number (Step 1.6)
• Poll Interval (Minutes) — how far back Q360 looks for new transactions on each run (default 240)

Note: The following settings are configured elsewhere in Q360, not on this screen:
– Card liability GL and employee reimbursement liability GL — on the RAMP-PAID and RAMP-UNPAID expense pay codes (Step 2.5)
– Reimbursement Bank Account — on the Company Map (Step 1.8)
– Default branch and department — set through the standard process of creating records in Q360

Saving stores your settings. It does not push anything to Ramp — that happens in Step 2.5.

If you are changing vendor sync mode (e.g. from Active Only to Report-Based): vendors that were already queued under the previous mode will still attempt to process and may fail. These failures can be safely ignored — check Sync Error History and disregard errors for vendors that were queued before the mode change.

2.4 Receipts

From Ramp to Q360 (automatic). Receipt images captured in Ramp download into Q360 with the transaction — on the expense for card transactions and reimbursements, and on the voucher for bills. No setup is needed in Q360, but your Ramp API application must include the receipts scope (Ramp-side guide Step 2).

From Q360 to Ramp (optional). If you want employees to forward receipts from Q360 to Ramp, get the receipt inbox email from Ramp and enter it in the Receipt Email setting.

When configured, a Ramp Receipts tab appears on the Expenses form. Users upload files there (JPG, PNG, or PDF only), right-click, and choose Forward Receipt to Ramp. Other file types are blocked. If this setting is left blank, the tab does not appear.

2.5 Register with Ramp

Register Service is the deliberate push that sends your data to Ramp: GL accounts, expense categories, the six custom accounting fields, vendors (per your sync mode), and entity mapping. It also creates the Ramp payment types, payment terms, and expense pay codes in Q360 automatically.

• Click Register Service on the Authentication tab
• Check View → My Background Jobs and wait for status to show Success
• If it fails, fix the issue and click Register Service again — re-running is safe and fills in anything missing

Duration: Registration time depends on data volume. With report-based vendor sync and a few hundred active records (projects, calls, opportunities), expect 2–10 minutes. With sync-all on a large dataset, it could take several hours. The process runs in the background — Q360 remains fully usable while it completes.

Verify in Ramp after registration (use Ctrl+K to search):

• GL accounts appear in Chart of Accounts
• Expense categories appear as additional GL accounts in Chart of Accounts
• Six custom accounting fields exist: Q360 ProjectNo, Q360 CallNo, Q360 OpporNo, Q360 Branch, Q360 Department, Bill to Customer
• Vendors appear (if your sync mode includes them)

Verify in Q360 after registration (Maintenance → General Codes):

• EXPENPAY (expense pay codes):
• RAMP-PAID — GL Account is your card liability GL (Step 1.7). Card transactions credit this account.
• RAMP-UNPAID — GL Account is your employee reimbursement liability GL (Step 1.8), and the Reimburse flag is set. Reimbursements use this account.
• Ramp payment type codes exist (type = PAYTYPE): RAMP_ACH, RAMP_CARD, RAMP_CHECK, RAMP_DOMESTIC_WIRE, RAMP_INTERNATIONAL, RAMP_LOCAL_BANK_XFER, RAMP_OT_CARD, RAMP_OT_CARD_DLVRY, RAMP_PAID_MANUALLY, RAMP_SWIFT
• RAMP payment terms code exists (type = PTERMS)

Verify on the Company Map: every company that receives reimbursements shows a Reimbursement Bank Account (Step 1.8).

Ramp-side steps required after registration:

1. Restrict expense categories to card and reimbursement forms (not bills)

Expense category GL accounts (e.g. MEALS, TRAVEL) appear in Ramp’s chart of accounts alongside regular GL accounts. Restrict them so they only show on card transactions and reimbursements — not on bills — otherwise employees will accidentally pick them when coding bills.

• In Ramp, go to Chart of Accounts and create a Chart of Accounts Workflow that shows expense categories only for card transactions and reimbursements
• Ask your Ramp admin or Solutions360 contact if you need help with the workflow builder

2. Configure Q360 custom field visibility and export rules in Ramp

Q360 registration creates the six custom fields in Ramp, but they will not appear on employee expense forms until the Ramp admin configures them. These steps require a full Admin role in Ramp (IT-Admin does not have access). See the Ramp-side setup guide (Steps 4B and 4D) for details.

• Add all six Q360 fields to the Submission Policy and confirm they are enabled for all expense types (including Mileage and Reimbursements)
• Verify “Required for export” is OFF for Project, Call, and Opportunity — Q360 expects at least one object type on an expense, not all three. Ramp does not support an “at least one of” rule, so validation is handled on the Q360 side.

2.6 Vendor crosswalk (Ramp vendor ↔ Q360 vendor)

Prerequisite: Register Service (Step 2.5) must complete successfully before the crosswalk can be used. Attempting to link or process vendors before registration will fail.

The crosswalk links each Ramp bill vendor to a Q360 vendor. Bills import only for linked vendors.

Q360 builds the crosswalk from your bills. When a bill arrives from a Ramp vendor Q360 has not seen before, the vendor is added to the crosswalk as Unlinked and the bill waits. Sync Error History names the vendor and the bill. Once you link the vendor, the waiting bill imports on the next sync — no need to resubmit it in Ramp. Card and reimbursement merchants do not appear in the crosswalk.

To resolve a vendor:

• Open the Vendor Crosswalk tab
• Review each row — the system suggests a match:
• 100% match — exact name match; action set to LINK automatically
• Partial match — similar name; needs your review (action shows PENDING)
• No match — nothing similar found (action shows PENDING)
• Set the action for each row:
• LINK — connect this Ramp vendor to an existing Q360 vendor
• CREATE — create a new Q360 vendor from the Ramp data and link them
• NOLINK — exclude this vendor; bills for them will not import
• Select all resolved rows, right-click, and choose Process Selected

Optional — link vendors before go-live. If you already pay vendors through Ramp, click Import Ramp Vendors to load Ramp’s vendor list into the crosswalk and link them up front, so the first bills do not wait. (This does not create vendor records in Q360.)

NOLINK is not permanent — you can change it later and reprocess. A Q360 vendor can only be linked to one Ramp vendor.

2.7 Push vendors to Ramp

Sends your Q360 vendor data to Ramp per your sync mode. After the first push, vendors sync automatically each time they are saved in Q360.

Sync All or Active Only:

• On the Vendor Crosswalk tab, click Export Q360 Vendors (available once all crosswalk rows are resolved)

Report-Based:

• Go to Live Data → Ramp Sync Vendors (Report Q0404), select vendors, right-click → Push to Ramp
• Check Synced Vendors and Sync Error History for results — common failures are missing state or missing email

2.8 Background job (ongoing import from Ramp)

This scheduled job pulls in new bills, reimbursements, card activity, and receipts. Set it up once.

• Go to Maintenance → Background Job Administration and click Add (+)
• In the Job SQL field, click the pencil icon and select the Integration: Process Queue template
• Set the @ps_Service parameter to 'RAMP'
• Name the job Ramp: Process Queue
• Set Frequency Type to MINUTES, Frequency Interval to 3
• Click Save, then Install Job

The polling interval (how far back Q360 looks for new transactions on each run) defaults to 4 hours and does not need to be changed. This setting is visible in Maintenance → API Config → Ramp as “Polling Interval.”

To trigger it immediately during testing: find the job in Background Job Administration and click Run Job. Check View → My Background Jobs to confirm it is running.

2.9 Final Ramp check (with your Ramp admin)

Verify the following in Ramp (use Ctrl+K to search by name):

• GL accounts are populated in Chart of Accounts
• Expense categories appear in the chart of accounts
• Six custom accounting fields exist with correct dropdown options (as of June 2026: Accounting > Settings > Accounting Fields)
• Pushed vendors appear (if you pushed vendors)
• Bank accounts for each entity have GL accounts assigned for cards, reimbursements, and bill pay (Ramp guide Step 4A)
• Chart of Accounts Workflow is configured so expense categories only show on card transactions and reimbursements (Ramp guide Step 4C)
• Submission Policy includes all six Q360 custom fields, enabled for all expense types including Mileage (Ramp guide Step 4D)
• “Required for export” is OFF for Project, Call, and Opportunity fields (Ramp guide Step 4B)
• Transaction splitting is disabled (Ramp guide Step 4E)

---

3. Go-Live

3.1 Pick a cutover date

• Choose a clear date — usually a month boundary
• The integration does not backfill history before that date; plan how to handle pre-cutover items separately
• Communicate the date to accounting and field users

3.2 Test a small set

• Bill: Approve a small bill in Ramp. In Q360, confirm a posted AP voucher with the correct vendor (from the crosswalk), correct bank, and post date matching Ramp’s accounting date. Any invoice images on the bill are attached to the voucher. When Ramp marks it paid, confirm the payment posts from your Ramp AP Bank Account.
• Reimbursement (synced before it is paid): Approve a reimbursement and mark it ready to sync before Ramp pays it. Confirm a posted expense and an open voucher to the employee’s Default Vendor, both dated to Ramp’s accounting date. After Ramp pays the employee, confirm the voucher is paid automatically on Ramp’s payment date, from the Reimbursement Bank Account.
• Reimbursement (already paid through Ramp): Confirm a posted expense and a voucher that is already paid. The voucher is dated to the accounting date and shows Ramp’s payment date as its paid date.
• Reimbursement (paid outside Ramp): Mark a reimbursement as paid outside Ramp. Confirm the expense appears as approved and unposted, with no voucher — post and pay it in Q360 as you normally would (Q360 does not record a payment it did not initiate).
• Company card: Approve a test card expense. Confirm a posted expense and a journal entry that debits the expense category’s GL and credits your card liability GL (Step 1.7). No voucher is created.
• Receipts: For any test item with a receipt in Ramp, confirm the receipt is attached in Q360. Receipts can take 2–3 sync cycles to appear after the item itself.
• Check Sync Error History for any failures

3.3 GL and coding spot-check

• Open imported expenses and vouchers; confirm GL, project, call, branch, and department are correct
• For card activity, confirm the journal entry credits the card liability GL
• For reimbursements, confirm the voucher relieves the employee reimbursement liability — the expense account should be debited once, by the expense
• Open the Merchant Spend Report (Maintenance → API Config → Ramp → Settings tab) and confirm your test card charges appear under the right merchant
• Confirm all imported items show EXEMPT tax treatment (Ramp handles tax; Q360 does not recalculate)

3.4 Train your people

• Walk through the Ramp dropdowns that came from Q360 (projects, calls, branches, departments, expense categories)
• Card transactions and reimbursements must be coded to an expense category (e.g. MEALS, TRAVEL), not a GL account. Bills use GL accounts directly. The Ramp-side workflow controls what users see in the dropdown, but if it is misconfigured, transactions coded to GL accounts instead of categories will not process correctly in Q360.
• Remind them: vendors are owned in Q360 and flow one-way to Ramp — edits made only in Ramp can be overwritten on sync
• Receipts attached in Ramp come across to Q360 automatically; cover receipt forwarding from Q360 if you turned it on (Step 2.4)
• Splitting transactions in Ramp is not supported and must be disabled before go-live. Your Ramp admin should confirm the split toggle is off in Settings → Policy → Expense Requirements and that no Split expense automations exist in Settings → Policy → Accounting Rules (see the Ramp-side setup guide, Step 4E). Employees should always code each transaction to a single GL account, project, and cost center.

3.5 Monitor the first few weeks

• Check Sync Error History daily at first
• Check the Vendor Crosswalk for Unlinked vendors — their bills are waiting
• Review Synced Vendors while you are still cleaning vendor data
• Do a clean month-end close with the new data

---

4. Ongoing: What Happens Automatically

When someone changes data in Q360:

What changes in Q360	What happens in Ramp
Vendor saved (within sync mode)	Vendor created or updated in Ramp
AP-Main contact updated on a Ramp-linked vendor	Other vendor details updated in Ramp, but email address will not update — Ramp does not have an API endpoint for this. You must also update the email manually in Ramp.
GL account saved	GL updated in Ramp
Vendor deactivated	Marked inactive in Ramp
GL deactivated	Marked inactive for coding in Ramp
New project, call, branch, department, or category saved	Appears in the corresponding Ramp dropdown automatically — no need to re-run Register Service

When something happens in Ramp:

In Ramp	In Q360
Bill approved, vendor linked, entity mapped	Posted AP voucher; post date from Ramp accounting date; invoice images attached; payment from Ramp AP Bank when Ramp marks paid. Note: Opportunity is not carried over to bills.
Bill from a vendor not yet in the crosswalk	Vendor added to the crosswalk as Unlinked; bill waits and imports on the next sync after you link the vendor. Logged in Sync Error History.
Bill from a NOLINK vendor	Not imported; logged in Sync Error History
Reimbursement synced before it is paid	Posted expense + open voucher to the employee’s Default Vendor, dated to the accounting date
Reimbursement paid through Ramp	Voucher paid on Ramp’s payment date from the Reimbursement Bank Account — whether it was paid before or after it synced
Reimbursement paid outside Ramp	Expense approved but unposted, no voucher — post and pay it in Q360
Unpaid reimbursement cancelled or rejected after it synced	Its voucher and expense are removed from Q360. If the period is closed, nothing changes and Sync Error History says so — reverse it manually.
Company card charge approved	Posted expense + journal entry: debit the expense category’s GL, credit the card liability GL. No voucher.
Receipt attached in Ramp	Attached to the matching expense or voucher in Q360, usually within 2–3 sync cycles
Activity from an unmapped entity	Skipped; logged in Sync Error History
Bill, reimbursement, or card transaction split within Ramp	Not supported. Only the first line item’s coding carries through to Q360. The split is not replicated. See the note below.

Limitation — Ramp splits: If a bill, reimbursement, or card transaction is split within Ramp (divided across multiple GL accounts or cost centers before syncing), that split does not write back to Q360. Only the first line item’s coding is carried through. Branch and Department apply to the whole bill, not to individual lines. If your team regularly uses Ramp’s split feature, make sure they understand this before go-live.

Paid reimbursements are not reversed automatically. If a reimbursement was already paid when it was cancelled in Ramp, correct it manually in Q360.

---

5. Troubleshoot Symptoms

Symptom	Common cause	Where to look
Vendor did not go to Ramp	No AP-Main contact (expected behavior if no default email set)	Add AP-Main contact to vendor, then edit and re-save the vendor record
Vendor did not go to Ramp	U.S./CA vendor missing state	Fix vendor address in Q360
Bill did not import	Vendor is Unlinked in the crosswalk	Link the vendor in the Vendor Crosswalk (Step 2.6); the bill imports on the next sync
Bill did not import	Company not mapped	Company map (Step 2.2)
Reimbursement stuck	Emails do not match	Q360 user email vs. Ramp user email
Reimbursement did not import	Employee has no Default Vendor	Employee record (Step 1.4)
Reimbursement not marked paid	No Reimbursement Bank Account for the company	Company Map (Step 1.8)
Card transaction or reimbursement did not post	Expense pay code missing its GL	RAMP-PAID / RAMP-UNPAID in General Codes (Step 2.5)
Item did not import	Accounting period is closed	Open the AP/GL period (Step 1.10)
Receipt not attached yet	Receipts follow the item by 2–3 sync cycles	Wait for the next cycles; if still missing, check Sync Error History and the Ramp API receipts scope
Nothing new importing from Ramp	Background job not running	Ramp: Process Queue job in Background Job Administration (Step 2.8)
Registration error	API credentials or data issue	Test Connection (Step 2.1) to confirm auth, then Register Service again

Sync Error History — from the Ramp config page or the report list — is always the first place to read the why.

---

6. Upgrade from an Earlier Release to v26.05

If your integration was set up before Q360 26.05, a few things work differently after you upgrade. Nothing you imported earlier is changed.

Card transactions (26.04)
– New card transactions post as an expense plus a journal entry, with no voucher. Card transactions imported before the upgrade keep their vouchers.
– The CC liability vendor (e.g. “Ramp General”) is no longer used for new card transactions.
– Confirm the RAMP-PAID expense pay code points to your card liability GL (Step 2.5).

Vendor crosswalk (26.04)
– Bills from vendors not yet in the crosswalk now wait as Unlinked instead of failing. Check the crosswalk regularly (Step 2.6).

Reimbursements (26.05)
– Reimbursements now create a posted expense and a voucher that is paid automatically when Ramp pays the employee (see the table above).
– Before the first sync after upgrading, click Register Service again (safe to re-run), then confirm:
– RAMP-UNPAID has your employee reimbursement liability GL and the Reimburse flag set (Step 2.5)
– Each company that receives reimbursements has a Reimbursement Bank Account on the Company Map (Step 1.8)
– Each employee who submits reimbursements has a Default Vendor (Step 1.4)

Receipts (26.05)
– To bring receipt images into Q360, your Ramp admin adds the receipts scope to the Q360 API application in Ramp (Ramp-side guide Step 2). Then click Test Connection in Q360 to confirm the connection still works.

Permissions (26.04)
– You can now give non-admin finance staff access to the integration (see Who can manage the integration).