Payments
Ramp
Connect your AI to Ramp
Finance and accounting teams, controllers and AP managers, and department and card program managers run corporate spend through Ramp, but the answers they need are spread across transactions, bills, reimbursements, vendors and cards. AI can bring those together in seconds, but only if it keeps to read-only access, shows only the spend data the connected Ramp user's role permits, and treats card, bank account and receipt details as sensitive financial data.
Why it matters
Capabilities that matter most for Ramp
01
Ramp spend next to your ledger
Prompts pair Ramp with Business Central, Dynamics GP, Sage Intacct and Rillet to find spend that never reached accounting.
02
Ready-made Ramp tools and prompts
Install more than 150 Ramp tools and ready-made prompts from the app store, so bills due, unsynced spend and reimbursements are one question away.
03
Governed AI over company spend
AI answers within the connected Ramp user's role and treats card, bank account and receipt details as sensitive.
Use cases
Example AI Use Cases for Ramp
scenario
-
When a new vendor is set up in Ramp, someone has to retype it into Dynamics GP by hand. They search GP to see whether the vendor is already there, invent a vendor id, and key in the name and country. A missed search creates a duplicate vendor, and a typo in the name or id means bills and payments go to the wrong record.
What popdock provides
--
Give the Ramp vendor name, and optionally the Dynamics GP company and a vendor id. It reads the vendor from Ramp, then checks Dynamics GP for an existing vendor with the same name or id and stops if one is found. You see the exact vendor id, name, country and status it will send, and if you gave no id it proposes one and asks. Nothing is written until you say yes, then it creates the GP vendor with a single write and reads it back. It does not invent addresses or payment terms and never changes anything in Ramp.
Business outcome
---
New Ramp vendors reach Dynamics GP once, with the right name and id, and no duplicate vendor records to clean up later.
scenario
-
New vendors are set up in Business Central and then re-keyed into Ramp by hand. Someone has to work out which vendors are missing, retype names, emails and countries, and hope nothing is mistyped. Vendors get skipped, spelled differently or entered twice, and the gap only shows up when a bill cannot be paid.
What popdock provides
--
Name a vendor or leave it open, and it finds active Business Central vendors that are missing from Ramp and shows them to you. You choose which ones to create. It adds them to Ramp one at a time with the Business Central vendor number as the external id, then reads each back. Vendors with no email or country are listed instead of filled in, and close name matches go on a review list rather than being created. Nothing is updated or deleted.
Business outcome
---
Vendors set up in Business Central reach Ramp once, with matching ids and no invented details, so payments are not held up by re-keying.
scenario
-
Setting up a vendor in Ramp by hand means searching the vendor list first, under both the trading name and the legal name, to avoid creating the same company twice. Then someone has to remember whether an agreement belongs on file, and its dates, value and renewal terms get typed in differently each time.
What popdock provides
--
Give a vendor name, country and contact email, and optionally an agreement end date, and it checks Ramp for similar vendors by name and by legal name before anything is written. If a match exists it shows it and stops unless you say this is a different vendor. You see the vendor and agreement details and confirm, then it creates them and reports the new ids and anything left to do. It never deletes vendors and never touches bank details.
Business outcome
---
New vendors and their agreements are created once, with consistent terms, and bank details stay in your hands inside Ramp.
scenario
-
The accounting data Ramp uses to code spend, such as GL accounts, fields, tax rates and vendors, drifts over time. Inactive accounts stay required, vendors never sync, and duplicate names creep in, so spend is miscoded and syncs fail. Finding them means opening each set one at a time.
What popdock provides
--
Ask for an audit, optionally limited to names containing a word, and it reads Ramp GL accounts, accounting vendors, fields, tax rates, tax code options and inventory item options. It flags inactive entries still required for a spend type, unsynced or uncategorised vendors, tax rates with no GL account or a suspicious percentage, duplicate names, and signs of two accounting connections. Nothing is changed. An empty set is reported as empty, not as clean.
Business outcome
---
Mapping problems that cause miscoded spend and failed syncs are listed in priority order before they reach month end.
scenario
-
Chasing missing receipts means pulling card transactions, pulling uploaded receipts, and matching one list against the other by hand. Small purchases get ignored, the same people get chased repeatedly, and no one has a clear picture of how much spend is undocumented.
What popdock provides
--
Say how far back to look and the minimum amount, and it reads Ramp card transactions for that window, drops declined ones, then reads the receipts uploaded in the same period. Transactions with no receipt are grouped by cardholder with date, merchant, amount and currency, biggest total first. It tells you how many were checked and how many lack receipts, warns about receipts uploaded before the window, and warns if a list may be truncated. Nothing is changed.
Business outcome
---
You know exactly who owes which receipts, ordered by value, without matching two lists yourself.
scenario
-
Purchase orders, bills and receipts live in different places in Ramp. Matching them by hand means comparing amounts, billing status and receipt status for each order, so goods that were paid for but never received, or received but never billed, go unnoticed until someone asks.
What popdock provides
--
Say how far back to look, and optionally a billing status, and it reads Ramp purchase orders created in that window. It flags orders billed but with nothing received, received but not billed, and spend above the order amount. For each suspect order it checks item receipts and line items to confirm quantities. You get three sections with PO number, name, amount, spend total, billing and receipt status. Nothing is changed.
Business outcome
---
Paid-but-not-received, received-but-not-billed and overspent orders surface in one report instead of being found by chance.
scenario
-
At close, finance hunts through card transactions and bills to find what never reached the accounting system, then opens each one to guess why. A missing memo or accounting field is usually the cause, but finding it takes a transaction at a time.
What popdock provides
--
Say how far back to look and a minimum amount, and it reads Ramp card transactions and bills from that period and keeps the ones not synced, skipping declined transactions. For each unsynced transaction it checks the line items for a memo and accounting fields, the usual reason a sync is held. You get a table of transactions and one of bills with a likely reason for each, plus counts and totals per currency. It recommends and never fixes.
Business outcome
---
You see what is missing from the books and why before close, without opening each transaction.
scenario
-
Reviewing who has access to Ramp means paging through users, working out what each role allows, and spotting administrators, invitations that were never accepted and users with no manager or department. It is slow, so reviews get skipped or skimmed.
What popdock provides
--
Ask for an access audit, optionally for one role, and it reads Ramp users, roles and departments. It lists every user with an administrative role so you can confirm each is expected, then invited users who never became active, scheduled deactivations, active users with no manager or department, and managers who are no longer active. You get counts by status and role and a findings list with name, email and what to do. Nothing is changed.
Business outcome
---
Admin access and stale or incomplete user records are reviewed in one pass, with a clear action for each.
scenario
-
Leavers keep their Ramp access because nobody compares the Ramp user list with the Business Central employee list. Checking means opening both systems, matching people by number or name, and noticing who is no longer an active employee but can still spend. Name lookalikes make it easy to match the wrong person.
What popdock provides
--
Optionally give a last name to narrow the check, and it reads Ramp users and finds each person's Business Central employee record by employee number, or by name confirmed against email. It reports active Ramp users whose employee is not active, listing their Ramp role, plus users with no employee record and email mismatches. It never matches on a surname alone, marks ambiguous people as ambiguous, and shows both systems' raw statuses. Nothing is changed, it only recommends.
Business outcome
---
Leavers with live Ramp access surface in one report, with roles and evidence, so access can be removed before it is misused.
scenario
-
Posting a Ramp card transaction into Intacct by hand means looking up the transaction, checking whether someone already booked it, confirming the GL account is open, and keying the charge card entry. Miss the duplicate check or pick a closed account and the ledger carries a double posting or a failed entry that someone has to unwind later.
What popdock provides
--
Give a Ramp transaction id and the GL account to post to, and it reads the transaction from Ramp and stops if it is missing or declined. It then checks Intacct for an entry with the same payee, date and amount, and confirms the GL account exists and is active. You see the payee, amount, currency, date, charge card and account, and nothing is written until you say yes. It creates the charge card transaction once, never retries on failure, and reads the stored record back. The Intacct write has not been individually tested, so try it in a test company first.
Business outcome
---
Ramp card transactions are booked in Intacct once, to a valid GL account, with a read-back as proof and no duplicates to reverse.
scenario
-
Re-keying an approved Ramp bill into Rillet means copying the vendor, dates, amounts and expense lines across by hand. It is easy to book the same bill twice, code a line to the wrong account, or end up with line totals that do not add up to the bill amount.
What popdock provides
--
Give the Ramp invoice number, and optionally the vendor and the Rillet account code for the expense lines. It reads the approved Ramp bill and its lines, matches the vendor to an existing Rillet vendor, confirms the account is active, and checks Rillet for a bill with the same number. You see the exact vendor, dates, line amounts, account and currency, and nothing is booked until you say yes. It then reads the bill back from Rillet. Ramp is never changed.
Business outcome
---
Approved Ramp bills are booked in Rillet once, on a valid account, with line totals that match the bill.
scenario
-
Adding or removing people on a Ramp fund by name is easy to get wrong. Two people share a first name, the fund name is similar to another, or someone inactive gets added, and the wrong person ends up with spending access.
What popdock provides
--
Give the fund name, whether to add or remove, and the people, and it finds the fund and each person in Ramp. If the fund or any name matches none or several, it lists them and stops. Only active users can be added. You see the fund, the action and each resolved person with email and status, and confirm. It then applies the change in one step and reports the fund state. It never suspends members or terminates funds.
Business outcome
---
The right people are added to or removed from the right fund, with a clear record of what changed.
scenario
-
Ramp users code spend to GL accounts, and those accounts are meant to match the Dynamics GP chart of accounts. Over time accounts are added, renamed, made inactive or switched to non-posting in GP while Ramp still offers the old ones. Nobody notices until coded spend fails to post, often at month end, and the account formats differ between the two systems, so comparing by eye is slow.
What popdock provides
--
Optionally name a Dynamics GP company and an account type. It reads the GL accounts from Ramp and the chart of accounts from Dynamics GP, then matches them by account number and tells you if it had to normalise the codes, for example dashes between segments. The report lists active Ramp accounts with no GP account, matched accounts that are inactive, closed to entry or not posting accounts, names that differ materially, and active GP posting accounts missing from Ramp. It only reads, changes nothing in either system, and stops if either side returns no accounts.
Business outcome
---
Account mismatches are found and fixed before coded spend fails to post, without a manual comparison of two charts.
scenario
-
Ramp GL accounts have to line up with the Intacct chart of accounts, but the two are maintained separately. A code that was never created, a closed account, or one that blocks direct posting only shows up when a sync fails, usually during close.
What popdock provides
--
Name a filter, or leave it empty for everything, and it reads the active GL accounts in Ramp and the matching accounts in Intacct. It matches them by account code, ignoring padding and leading zeros, and sorts each into matched, no Intacct account, inactive in Intacct, direct posting disallowed, or titles that differ materially. The report is grouped by verdict with problems first and counts. Nothing is changed in either system. With no filter it reads up to the record limit and tells you the list may be cut short.
Business outcome
---
Broken account mappings are found and listed before a sync fails, so you can fix them in Ramp or Intacct on your own schedule.
scenario
-
Ramp GL accounts are synced to a chart of accounts that drifts from Business Central. Spend ends up coded to accounts that do not exist, are blocked, or are closed to direct posting, and the problem shows up when the sync or the posting fails. Checking means comparing two account lists line by line.
What popdock provides
--
Optionally give part of an account name, and it reads the active Ramp GL accounts and looks up each code in the Business Central chart of accounts. It reports codes that are missing, blocked, closed to direct posting or named differently, plus Ramp accounts with no code, then ranks the top fixes. A name difference is not called a mismatch when the code matches. If Ramp returns no accounts it stops, and neither system is changed.
Business outcome
---
Coding problems between Ramp and Business Central surface before they break a sync, with a ranked list of fixes.
scenario
-
Ramp spend is coded to general ledger accounts, and those codes have to exist in the Rillet chart of accounts. When a code is missing, renamed or inactive, nobody finds out until a sync fails and someone has to compare two account lists by hand.
What popdock provides
--
Ask for a comparison, and optionally limit it to codes containing some text or include inactive Ramp accounts. It reads the Ramp GL accounts and the Rillet chart of accounts, then matches each Ramp code to a Rillet account code. It lists Ramp codes missing from Rillet with a candidate account of the same name, matched codes whose names differ, and matched codes where the Rillet account is not active. Codes that appear twice on one side are flagged, not matched. Nothing is changed in either system.
Business outcome
---
Account code gaps between Ramp and Rillet are found and listed before they break a sync, with nothing changed.
scenario
-
Vendors get added to Ramp and Intacct by different people at different times. Names are spelled differently, one side is marked inactive, or the country does not agree, and nobody notices until a payment fails or a bill will not post.
What popdock provides
--
Give a vendor name, and optionally how many to check, and it reads the matching vendors in Ramp, then looks each one up in Intacct. You get one row per Ramp vendor showing the Intacct vendor id or missing, status on both sides, country on both sides, and a verdict: match, missing in Intacct, inactive mismatch, country mismatch or ambiguous. Names that differ only by case, punctuation or a suffix such as Inc or LLC count as the same. Nothing is created or changed in either system.
Business outcome
---
Vendor gaps between Ramp and Intacct are caught in one read, before a payment or a bill runs into them.
scenario
-
Correcting one line on a Ramp bill sounds small, but the bill may already be approved or paid, and the wrong line can be edited when several look alike. Without a before and after view, a change to a bill that should be locked can slip through.
What popdock provides
--
Give the bill and which line to change, plus the new amount or memo, and it reads the bill and finds the matching line. If the reference matches none or several, it lists the lines and stops. You see the line as it is and as it will be, with a warning if the bill is approved or not unpaid. Paid bills are refused. After you confirm it updates that one line and reads it back. It never deletes lines or archives bills.
Business outcome
---
One bill line is corrected with a clear before and after, and paid or approved bills are not changed by accident.
scenario
-
When a vendor already exists in Ramp, setting it up again in Rillet means retyping the name and email and finding an address Ramp does not hold. Skip the search and you create a duplicate vendor, and leave out a required address field and the vendor will not save.
What popdock provides
--
Give the Ramp vendor name, and the address details if you have them. It finds the vendor in Ramp, picks up the default contact email, and checks Rillet for the same name or email. If several Ramp vendors match, or Rillet already has the vendor, it stops and tells you. It asks for any missing required address field, shows the exact values, and creates the vendor only after you say yes. It then confirms the vendor appears in Rillet. Ramp is never changed.
Business outcome
---
Ramp vendors are created in Rillet once, with the required address details and no duplicates to clean up.
scenario
-
Setting up in Intacct a vendor that already exists in Ramp means re-keying the name, choosing an id, and first checking that no similar vendor is already there. A typo or a skipped search leaves a duplicate vendor that later splits bills and payments.
What popdock provides
--
Name the Ramp vendor, and optionally the Intacct vendor id to use, and it reads the vendor from Ramp, stopping if several match or it is inactive. It then searches Intacct for a vendor that looks the same and stops if it finds one. You see the vendor id, name and print as value, and nothing is written until you say yes. It creates the vendor once, never retries on failure, and reads the stored vendor back. The Intacct write has not been individually tested, so try it in a test company first.
Business outcome
---
New Intacct vendors match their Ramp record, are created once without duplicates, and come with a read-back to confirm what was stored.
scenario
-
Vendor lists in Ramp fill up with companies nobody has paid for years. Tidying them up risks deactivating a vendor that still has a live agreement, an open draft bill or an open purchase order, and finding that out means checking each vendor in several places.
What popdock provides
--
Say how old a vendor must be, and it finds active Ramp vendors with no spend in the last 365 days. It then excludes any with an agreement that has not ended, open draft bills or open purchase orders. You see the remaining candidates with created date and all-time spend and choose which to deactivate. Silence counts as no. Approved vendors are set to inactive and re-read to confirm. It never deletes vendors.
Business outcome
---
Dormant vendors are retired only when nothing still depends on them, and you decide each one.
scenario
-
Keying a bill into Ramp means finding the vendor, picking the business entity, and checking the invoice number was not already entered as a draft or a bill. Miss that check and the same invoice is paid twice.
What popdock provides
--
Give the vendor, invoice number, amount and optionally a due date, and it finds the vendor in Ramp and the business entity, asking which if there is more than one. It then checks existing draft bills and bills for the same invoice number and stops if one exists. You confirm the details, and it creates a draft bill with one line for the amount and reads it back. It only creates drafts and never submits, archives or deletes bills.
Business outcome
---
Invoices enter Ramp once, as reviewable drafts attached to the right vendor and entity.
scenario
-
When a fund needs freezing quickly, someone has to find the right fund, check its state and balances, and remember that suspending can affect pending transactions. Under pressure it is easy to pick the wrong fund or to act on one that is already suspended.
What popdock provides
--
Give the fund name and whether to suspend or restore it, and it finds the fund in Ramp. If none or several match, it lists them and stops. It shows the state, limit, pending, cleared and total balance, and stops if the fund is already in the requested state. It warns that pending transactions may be affected, waits for explicit confirmation, applies the one action and reads back the new state. It refuses to terminate funds.
Business outcome
---
The right fund is suspended or restored quickly, with its balances in view and permanent termination off the table.
scenario
-
Ordering a physical Ramp card needs the right active user, the right fund and a complete shipping address. It is easy to order a second card for someone who already has one, or to ship a card to a half-typed address.
What popdock provides
--
Give the person, the shipping address and optionally a fund, and it finds the active user in Ramp and shows any cards they already hold, so a second card is a deliberate choice. A named fund must match exactly one record. If the address lacks line 1, city, postal code or country it asks and never invents one. You confirm the user, fund and address, then it orders the card once and reports the card id and fulfilment status.
Business outcome
---
Cards go to the right person and a complete address, and duplicate orders happen only on purpose.
scenario
-
Mileage claims in Ramp are keyed by hand from an email or message. The same trip gets entered twice, or the distance and date are guessed because the original note was vague, and the reimbursement amount is wrong from the start.
What popdock provides
--
Give the employee, trip date, distance and route, and it finds the person in Ramp and checks reimbursements on that date for a claim of the same size. If one exists it shows it and stops. You see the person, date, distance with its unit and the start and end locations, and it asks if the unit is missing. After you confirm it files the claim once and reports the amount Ramp calculated. It never guesses distance or date.
Business outcome
---
Mileage claims are filed once, with the stated distance and date, and the calculated amount is confirmed straight away.
scenario
-
Purchase orders live in Ramp and again in Dynamics GP, and nobody confirms that the two agree. A PO can exist in one system only, carry a different amount, or show as fully received in Ramp while GP has no receipt. Checking means opening both systems, matching PO numbers whose formats differ, and comparing receipts line by line.
What popdock provides
--
Give a start date, and optionally a vendor and a Dynamics GP company. It reads the Ramp purchase orders created since that date, finds the matching Dynamics GP purchase orders by PO number and reads the GP receipts for the vendors involved. You get a table with each PO, the Ramp and GP amounts, the difference, the status on both sides and the number of receipts found. It flags POs missing on either side, differing amounts and receipt disagreements, and flags a currency mismatch instead of comparing. It only reads and never changes either system.
Business outcome
---
Purchase order and receipt differences between Ramp and Dynamics GP surface in one review, before they turn into payment disputes.
scenario
-
When someone leaves, their Ramp cards and access often stay live because nobody has a list of everything they hold. Physical cards, virtual cards, funds and unpaid reimbursements sit in different places, and deactivating the user without checking leaves loose ends.
What popdock provides
--
Name the leaver and it finds them in Ramp, stopping if the name matches none or several. It lists their physical cards, virtual cards, the funds they own or are named on, and reimbursements not yet paid. You see everything and the plan, which is to suspend each active physical card and then deactivate the user, and nothing happens until you confirm. It then re-reads the user and cards. Cards and funds are never terminated, and open reimbursements and funds are reported as follow ups.
Business outcome
---
Leavers lose card use and access once you confirm, and every open item is handed back as a follow up.
scenario
-
Inviting someone to Ramp means looking up the role and department by name, checking they do not already have an account, and choosing the right level of access. A slip creates a duplicate user or hands out more access than intended.
What popdock provides
--
Give the full name, email, role and optionally a department, and it checks Ramp for an existing user with that name and stops if one exists. It confirms the role exists, listing the available roles if not, and resolves the department, stopping if several match. It does not guess a location or manager. You confirm the details, it sends one invitation, then it checks the user shows as invited. Administrative roles are only used when you name them.
Business outcome
---
New users are invited once, with the role you chose and no accidental admin access.
scenario
-
Once a bill is approved in Ramp, someone rekeys it into Dynamics GP payables. They look up the vendor id, check the invoice was not already entered, then copy the amount, dates and batch details across. A missed check gives a duplicate invoice, and a copied figure or currency that is wrong means the payable is wrongly valued in the live company database.
What popdock provides
--
Give the invoice number, and optionally the Dynamics GP company and batch number. It reads the bill from Ramp and stops unless it is approved, finds the vendor in GP and checks the invoice is not already there. It also stops on a missing vendor or a currency mismatch. You see the vendor id, document number, dates, amounts, batch and voucher number it will use, and nothing is written until you say yes. It then creates the payables invoice with a single write and reads it back. It never writes to Ramp.
Business outcome
---
Approved Ramp bills reach Dynamics GP payables once, with the right values, and no duplicate or mis-valued invoices to reverse.
scenario
-
A bill paid through Ramp stays open in Rillet until someone records the payment there. Checking each paid bill against Rillet by hand is slow, so missing payments and amount differences go unnoticed until the AP ledger is off.
What popdock provides
--
Give a due-date range. It finds the Ramp bills in that range that Ramp shows as paid, matches each to its Rillet bill by invoice number, and looks for a payment in Rillet within 30 days after the end of the range. It reports bills paid in Ramp with no Rillet payment, payments whose amounts differ, bills missing from Rillet, and Rillet payments Ramp does not show as paid. Amounts are compared only in the same currency. It lists the exceptions and fixes nothing.
Business outcome
---
Unrecorded and mismatched bill payments are listed before the AP ledger drifts, with nothing changed in either system.
scenario
-
AP staff tick Ramp bills off against Business Central purchase invoices one at a time, searching by vendor invoice number in the posted and unposted documents. Bills that never posted, or posted with a different amount, are usually only found at month end. An invoice number reused by another vendor can fool a quick check.
What popdock provides
--
Give a due-date range, and optionally a vendor name, and it reads the Ramp bills and looks each up in Business Central by vendor invoice number, first as a posted invoice and then as an unposted one. It confirms the vendor name before accepting a match and compares amount and currency. You get bills posted and matching, posted with a difference, unposted and missing, with Ramp sync status shown. Bills with no invoice number are listed as unmatchable and duplicate numbers as ambiguous. Nothing is changed.
Business outcome
---
Missing, unposted and mismatched bills are found in one pass before month end instead of one invoice at a time.
scenario
-
Accounts payable checks Ramp bills against Dynamics GP payables invoices by hand. They list bills due in a period, search GP for each invoice number, and compare amounts. Missing invoices and wrong amounts are often found only at month end, when closing is already under pressure, and voided or non-invoice GP transactions clutter the search.
What popdock provides
--
Give a due-date range, and optionally a vendor and a Dynamics GP company. It reads the Ramp bills due in that range and finds the matching Dynamics GP payables transactions by invoice number, confirmed by vendor. Where there is no match by number it looks for the same vendor and amount and marks it probable. You get one table with each bill, the Ramp and GP amounts, the difference and a status of Matched, Amount differs, Probable or Missing, then GP invoices with no Ramp bill and totals. Voided GP transactions are ignored, amounts in different currencies are flagged, and a missing bill is never assumed to be a sync failure. Nothing is changed.
Business outcome
---
Missing and wrong-amount invoices are found during the month, in one table, instead of during the close.
scenario
-
Reconciling one vendor's bills between Ramp and Intacct means pulling both lists, lining up invoice numbers that differ in case or leading zeros, and comparing amounts, due dates and payment state by eye. Bills that exist on one side only, or that disagree, are easy to miss.
What popdock provides
--
Give a vendor name, and optionally how many days back to look (the default is 60), and it reads that vendor's bills from Ramp and Intacct. It matches them on invoice number, ignoring case and leading zeros, then compares amount, due date and payment state. You get three lists: bills in Ramp only, bills in Intacct only, and matched bills that differ with both values shown, ending with counts and the amount at stake. Currency mismatches are reported rather than compared, it stops if either side has no bills, and nothing is changed.
Business outcome
---
Every billing difference for a vendor between Ramp and Intacct is listed with both values, so you fix the right bills and nothing is guessed.
scenario
-
Matching Ramp bills to Rillet bills by hand means comparing invoice numbers and totals across two screens. Bills that were never booked, or booked for a different amount, slip through and payables are misstated at close.
What popdock provides
--
Give a due-date range. It reads the Ramp bills in that range, skipping rejected and deleted ones, then reads the Rillet bills and lines and totals each Rillet bill. Bills are matched by invoice number, and a close match on vendor, total and due date is marked Probable. The report shows Matched, Amount differs, Not in Rillet and Only in Rillet, problems first and largest difference first, with the total value not in Rillet. Amounts are compared only in the same currency, and nothing is changed.
Business outcome
---
Unbooked bills and amount differences are found before close, with the value at risk totalled and nothing changed.
scenario
-
At month end every Ramp card transaction has to be matched to an Intacct charge card entry by hand, comparing amount, date and merchant across two screens. Entries that never made it across, or made it across with the wrong amount, are easy to miss in a long list.
What popdock provides
--
Give a start and end date, and optionally some merchant text, and it reads the Ramp card transactions and the Intacct charge card transactions for that period. It matches them one to one on amount, a date within 3 days and a similar merchant and payee. You get Ramp transactions with no Intacct entry, flagging any that Ramp says are synced, Intacct entries with no Ramp transaction, and amount mismatches, with counts and totals. Nothing is created or changed in either system.
Business outcome
---
Month-end card spend is matched in minutes, and the unmatched items are listed so you chase only the ones that matter.
scenario
-
Purchase orders are raised in Ramp and in Business Central separately, and the two are compared by hand. Totals drift, orders exist on one side only, and nobody sees that Ramp spend has run ahead of what Business Central has invoiced until someone builds a spreadsheet.
What popdock provides
--
Give a start date, and optionally part of an order name, and it reads Ramp purchase orders and finds each one in Business Central by order number. It reports orders not found, orders with a different total, and orders where Ramp spend exceeds what Business Central has invoiced, with billing and receipt status alongside. Orders with no number are listed as unmatchable, and amounts are compared only in the same currency. Nothing is changed or archived in either system.
Business outcome
---
Order totals and billing progress are checked across both systems in one pass, so differences are caught while the order is still open.
scenario
-
Checking whether an employee's Ramp reimbursements made it into Intacct means finding the person in both systems, then comparing each reimbursement with Intacct reimbursements and expense reports by amount and date. Items on one side only, or paid in one place and not the other, are hard to spot.
What popdock provides
--
Give an employee id and a start date, and it finds the employee in Ramp, reads their reimbursements, then reads their Intacct reimbursements and expense reports. It matches by amount with dates within 7 days and reports items in Ramp only, items in Intacct only, and matched items whose payment status disagrees, ending with totals per side and the difference. Currency differences are reported rather than compared. If the employee is missing from Intacct it says so and still lists the Ramp items. Nothing is added or changed.
Business outcome
---
Reimbursement gaps between Ramp and Intacct for an employee are listed with totals, so nobody is left unpaid or paid twice.
scenario
-
Employee reimbursements approved in Ramp are not always booked in Rillet. Rillet records the employee as a vendor, so matching by name, amount and date means searching across systems by hand, and unbooked reimbursements go unnoticed.
What popdock provides
--
Give a date range. It reads the Ramp reimbursements in that range and the Rillet reimbursements and items, then maps each Rillet vendor to a name and email. A reimbursement is matched when the employee name or email agrees, the amount is equal in the same currency, and the dates are within 5 days. The report shows Matched, Not in Rillet and Amount differs, plus Rillet reimbursements with no Ramp counterpart. If no vendor matches an employee it says so. Nothing is added to either system.
Business outcome
---
Unbooked and differing reimbursements are listed with a reason for each, so none are missed, and nothing is changed.
scenario
-
Vendor credits are recorded in Ramp and credit memos in Business Central, and nobody checks that the two agree. Credits go missing on one side or get applied twice, and following one back means finding the bills it was applied to and the memo it should match.
What popdock provides
--
Name a vendor, and optionally a start date (default is the last 365 days), and it finds the vendor in Ramp, reads its credits and the bills they were applied to, then reads the vendor's posted credit memos in Business Central. It matches by reference number and reports credits and memos with no partner, amount differences, and whether the applied amount agrees with the remaining amount. It stops if more than one vendor matches, compares only in the same currency, and counts archived credits without listing them. Nothing is created or changed.
Business outcome
---
Lost or double-applied vendor credits are found in one comparison, with matched and unmatched items clearly separated.
scenario
-
Finance compares the Ramp vendor list with the Business Central vendor list by hand in spreadsheets. Vendors that are missing on one side, blocked in one system but live in the other, or recorded in a different country slip through until a payment fails.
What popdock provides
--
Optionally give part of a vendor name, and it reads vendors and their default contacts from Ramp and vendors from Business Central, up to 100 per side. It matches by email first, then by normalised name, and reports vendors in one system only, status conflicts and country differences. Partial name matches are listed as possible matches for a person to decide. It says when a side is cut off at 100 records, stops if either side is empty, and never creates, updates or deletes a vendor.
Business outcome
---
Vendor mismatches between Ramp and Business Central are caught in one report before a payment fails.
scenario
-
Ramp and Dynamics GP share no vendor id, so keeping the two vendor lists aligned means comparing names by hand. Suffixes like Inc or LLC and differences in punctuation hide real matches. Vendors with spend in Ramp can be missing from GP, and a vendor can be inactive in Ramp while still active or on hold in GP, which only shows up when a payment goes wrong.
What popdock provides
--
Optionally give a Dynamics GP company and a minimum Ramp spend over the last 365 days. It reads the vendors from Ramp and the payables vendors from Dynamics GP, then matches them by name after normalising case, punctuation and suffixes. Near matches are listed as probable, never confirmed, and when a name matches several vendors every candidate is listed. The report shows Ramp vendors missing from GP by spend, GP vendors with a balance that are not in Ramp, and matched vendors whose status disagrees, with counts. It stops if either side is empty and never creates or changes a vendor.
Business outcome
---
Vendor gaps and status conflicts between Ramp and Dynamics GP are visible in one review, with spend to show which ones matter most.
scenario
-
Someone compares the Ramp vendor list to the Rillet vendor list by eye. Names differ by suffix or punctuation, and a vendor that exists in only one system goes unnoticed until a bill fails to post.
What popdock provides
--
Ask for the comparison, optionally limited to names containing some text, and optionally including inactive Ramp vendors. It reads the vendors in both Ramp and Rillet and matches them by name after ignoring case, punctuation and suffixes such as Inc, LLC and Ltd. The report has four lists: in Ramp only with year to date spend, in Rillet only, matched with any country differences, and ambiguous. A name that fits several Rillet vendors is never guessed. It says so if a result is partial. Nothing is changed.
Business outcome
---
Vendors missing from either system are found before a bill fails to post, with the biggest Ramp spend first.
scenario
-
A bill paid through Ramp stays open in Rillet until someone records the payment, with the amount and date typed by hand. Record it twice, or against a bill whose amount differs, and the payables ledger no longer agrees with the bank.
What popdock provides
--
Give the Ramp invoice number, and optionally the Rillet account code and payment date. It confirms Ramp shows the bill as paid, finds the matching Rillet bill, and checks whether a payment of the same amount is already recorded. It stops if the bill is not paid, is missing from Rillet, is already paid, or the amounts differ. You see the bill, amount, currency, date and account, and nothing is recorded until you say yes. It then reads the payment back from Rillet. Ramp is never changed.
Business outcome
---
Paid Ramp bills are closed in Rillet once, with the right amount and date and no double payments.
scenario
-
Answering what we owe a vendor means opening Ramp for the bills and payment status, then Dynamics GP for the balance, invoices and payment applications, and lining them up by hand. Vendor names are not identical across systems, and an invoice that looks paid in one place can still be open in the other.
What popdock provides
--
Give a vendor name, and optionally a Dynamics GP company. It finds the vendor in both Ramp and Dynamics GP and stops to ask which one if either name is ambiguous. It then reads the Ramp bills with their approval and payment status, and the GP open balance, recent invoices and the payments applied to each document. The report shows the vendor identity on each side, then lists invoices that look paid in one system and unpaid in the other, matching invoice numbers to document numbers. Amounts in different currencies are shown side by side and not netted. It only reads and changes nothing.
Business outcome
---
One view of what is owed to and paid to a vendor across Ramp and Dynamics GP, with disagreements flagged, in place of two screens and a spreadsheet.
scenario
-
To judge one vendor, someone pulls spend from Ramp and open balances from Business Central separately, and the two views are never put side by side. A vendor blocked in Business Central can stay active in Ramp, and open amounts that disagree go unnoticed.
What popdock provides
--
Name a vendor, and it finds it in Ramp and Business Central and puts both views together: Ramp spend over 30 days, 365 days and all time, open bills and unused credits, alongside the Business Central balance, balance due and open posted invoices. It flags vendors blocked in Business Central but active in Ramp, open amounts that differ by more than 1 percent and overdue items. It stops if the name is ambiguous, shows both currencies instead of a difference when they differ, and says plainly when the vendor exists on one side only. Nothing is changed.
Business outcome
---
One vendor review shows spend, open bills, credits and balances from both systems side by side, with the risks flagged.
scenario
-
AI service costs are spread across providers, models, API keys and people. No single screen shows who is spending what, which keys are near their limit, or which usage looks unusual, so the bill is understood only after it arrives.
What popdock provides
--
Say how far back to look and a minimum cost, and it reads the AI usage Ramp tracks. It totals estimated cost by provider and model with token counts, flags keys near their spend limit, not recently synced, or inactive but still costing money, and flags team members marked anomalous plus the top five by cost. You get the totals, top keys, top members, anomalies and two cost-saving suggestions based on the numbers. Nothing is changed.
Business outcome
---
Leaders get one view of AI spend by provider, key and person, with the unusual items pointed out.
scenario
-
The raw Ramp audit log is long and flat. Spotting a role change, a bank account edit or a burst of activity from one actor means reading line after line, so risky changes are easy to skim past.
What popdock provides
--
Say how far back to look, and optionally one user, and it reads up to 500 recent audit events. It groups them by event type and by actor, separating people from agents and system actors. It flags role, permission, bank account and integration changes, bursts of the same event from one actor, agent activity a person did not start, and activity outside normal hours. You get counts by type and findings with time, actor, event and why it matters. It describes events and never accuses anyone.
Business outcome
---
Sensitive and unusual changes stand out in a short findings list, with a suggestion of who should confirm each.
scenario
-
Someone scans the Ramp bills list by hand to see what is due, and the bills that need action are easy to miss: unapproved ones that cannot be paid, overdue ones, and bills that never synced to accounting.
What popdock provides
--
Say how many days ahead to look, and optionally one vendor, and it reads the Ramp bills due in that window. It marks bills overdue or due within three days and unpaid as urgent, bills not approved as blocked, and bills not synced to accounting, and groups several bills from one vendor. You get a table by due date with a one-line action for each, totals per currency, and the three bills to handle first. Currencies are never added together. Nothing is changed.
Business outcome
---
You know which bills need action first and why, without scanning the whole list.
scenario
-
Fund limits and balances in Ramp are checked one fund at a time, so a fund close to its limit, a suspended fund, a large temporary limit or a spend program with no transaction limit can sit unnoticed.
What popdock provides
--
Ask for a review, optionally for names containing a word, and it reads Ramp funds and spend programs. It flags funds over 90 percent of their limit, suspended funds and who suspended them, temporary limits that raise a fund well above normal, very large limits compared with the rest, and programs with no transaction limit. You get two tables and a short list of recommended changes. Amounts are not totalled across currencies, and nothing is changed.
Business outcome
---
Risky, stuck and unusually large limits are found in one review, with recommended changes you can act on.
scenario
-
Reimbursement claims in Ramp are often approved one by one, so nobody sees the same claim entered twice, a claim far above the norm, a claim with no memo or receipt, or one that never reached accounting.
What popdock provides
--
Say how far back to look and a minimum amount, and it reads Ramp reimbursements for that window. It flags large claims compared with the median, claims with no memo, repeated user and merchant pairs or repeated amounts, and claims not in accounting. It then reads receipts from the same period and marks claims with none. You get a table of flagged claims with user, merchant, date, amount and flag, then totals by user. Nothing is changed.
Business outcome
---
Large, repeated, undocumented and unsynced claims are flagged before approval, not after.
scenario
-
At period close, card statements, cashback and repayments in Ramp have to be reconciled by hand. Checking that each statement's balances add up, and finding cashback or repayments that never synced or never completed, takes time that close does not leave.
What popdock provides
--
Say how many months back to look and it reads Ramp card statements, noting opening balance, charges, credits, payments and ending balance. It checks that opening balance plus charges minus credits minus payments equals the ending balance, and flags any statement that is off by the difference. It then reads cashback and repayments and flags those not synced and repayments not completed. You get a table per statement, cashback and repayment tables, and the open items. Currencies are not combined and nothing is changed.
Business outcome
---
Statement arithmetic and open cashback and repayment items are checked before close, not found afterwards.
scenario
-
Vendor credits in Ramp can sit unused because nobody matches them to the bills still waiting to be paid. Working out which credits have a balance left, where they were already applied, and which open bills they could cover is a manual search.
What popdock provides
--
Say how far back to look, and optionally one vendor, and it finds Ramp vendor credits with a remaining balance that are not archived. It checks where each credit was already applied, then lists unpaid bills in the same currency that each could cover. You get a table with vendor, credit reference, remaining amount, currency, age and candidate bills, with remaining credit totalled per currency. It recommends only. Applying the credit is left to you in Ramp.
Business outcome
---
Unused vendor credits are matched to open bills so you can apply them before paying in full.
scenario
-
Vendor spend, contacts, bank details and agreements live in different places in Ramp. A large vendor with no contact, no default bank account or no agreement goes unnoticed, while dormant vendors clutter the list.
What popdock provides
--
Set a spend threshold and it ranks Ramp vendors by their last 365 days of spend with each one's share of the total. For the top ten it checks for a contact with an email, a default bank account and an agreement, and flags the gaps. It also lists active vendors with no spend in a year as clean-up candidates. You get a ranked table with flags, a dormant list and three recommendations. Only the last four digits of a bank account are shown, and nothing is changed.
Business outcome
---
You see where the money goes and which vendor records are weak, with three clear recommendations.
scenario
-
Auto-renewing vendor agreements slip past their cancellation date because nobody is watching end dates. By the time someone notices, the agreement has renewed for another term and the notice window has closed.
What popdock provides
--
Say how many days ahead to look and it reads the Ramp vendor agreements ending in that window. It marks agreements with auto-renewal that end within 30 days as urgent, noting the last date to terminate, flags agreements that will lapse so you can check the service is still needed, and notes any renewal already in progress. For each vendor it adds the last 365 days of spend beside the agreement value. You get a table by end date with a one-line recommendation. Nothing is changed.
Business outcome
---
Renewals and cancellations are decided before the notice window closes, with spend in front of you.
scenario
-
Account codes in NetSuite and the GL accounts in Ramp fall out of step, and the gap shows up as coding errors when expenses sync. Comparing the two lists by hand means matching codes, then names, and watching for inactive accounts.
What popdock provides
--
Optionally give part of an account name, and it reads the NetSuite chart of accounts and the Ramp accounting GL accounts. It matches NetSuite account numbers to Ramp codes first, then falls back to names and labels name-only matches as probable. The report covers matched accounts with their Ramp active and visibility status, NetSuite only, Ramp only, and pairs whose names differ, and notes if the Ramp provider is not NetSuite. If Ramp has no synced accounts it says so and stops. Only read operations are used on both systems.
Business outcome
---
Missing, inactive and mismatched accounts between NetSuite and Ramp are listed before they cause coding errors, with nothing changed.
scenario
-
Vendor lists in NetSuite and Ramp drift apart, and a vendor with an open balance that is inactive in Ramp, or one with spend and no NetSuite record, can go unnoticed for months. Matching names across two systems by hand is slow because of Inc, LLC and punctuation differences.
What popdock provides
--
Optionally give part of a vendor name and a cap, and it reads vendors from NetSuite, with balance, and from Ramp, with year-to-date spend. Names are matched after ignoring case, punctuation and suffixes such as Inc, LLC, Ltd and Corp, and close but not identical names are labelled probable. The report has matched vendors with NetSuite balance next to Ramp spend, NetSuite only, and Ramp only, flagging vendors with a balance that are inactive in Ramp and vendors with Ramp spend but no NetSuite record. It says when a cap is hit and the comparison is partial. It only reads.
Business outcome
---
Vendors that exist in only one system, or owe money while inactive in Ramp, are found without a manual name match, with nothing changed.
scenario
-
When someone leaves, HR ends their NetSuite employee record, but nobody compares that list with Ramp users. A leaver can keep an active Ramp login with nobody noticing.
What popdock provides
--
Give a department, or leave it blank for everyone, and it reads NetSuite employees with their hire and termination dates and the list of Ramp users. They are matched on email, or on last name plus employee ID at low confidence when an email is missing. The report lists employees with no Ramp user, Ramp users with no employee in scope, and employees whose termination date has passed but whose Ramp user is still active, with their Ramp role. It only reads and never deactivates or edits a user, and it says when the Ramp list may be incomplete.
Business outcome
---
Leavers with live Ramp access, and mismatched user lists, are named so IT can act, with nothing changed by the report.
scenario
-
Knowing what you owe and spend with one vendor means logging in to NetSuite and Ramp and piecing the two together. Balances, bills, payments and credits sit in different places, and a bill in one system can be missing from the other.
What popdock provides
--
Give a vendor name, and optionally how many days to look back (90 by default). It finds the vendor in NetSuite and in Ramp, and stops with a list if a name matches several. It then reads NetSuite bills, payments and balance, and Ramp bills, credits and spend. The report sets the NetSuite balance beside Ramp year to date spend, shows bills with Ramp payment status, payments in the window and remaining vendor credits, and closes with discrepancies such as a Ramp bill with no NetSuite bill of the same number. If the vendor is in only one system it shows that side. Nothing is changed.
Business outcome
---
One vendor view across NetSuite and Ramp, with discrepancies listed, replaces logging in to two systems and changes nothing.
scenario
-
An employee's expense reports in NetSuite and their reimbursements in Ramp have no shared reference. Someone lines them up by date and memo from two screens, so reports with no payment and payments with no report are hard to see.
What popdock provides
--
Give an employee email and a date range and PopdockAI reads that employee's NetSuite expense reports and their Ramp reimbursements for the period. With no shared document number, it pairs them by employee, by date within 5 days and by how similar the memo text is, and labels every pairing exact or probable. Paired items, reports with no reimbursement and reimbursements with no report are listed with the Ramp sync status and NetSuite status, and the Ramp amounts are totalled. It says that NetSuite report totals are not returned, lists candidates instead of guessing and changes nothing.
Business outcome
---
Finance sees which expense reports have no Ramp reimbursement and which reimbursements have no report, with each pairing labeled exact or probable.
scenario
-
Purchase orders live in NetSuite and again in Ramp, and checking a vendor's orders in both by hand lets missing orders through. A Ramp order can also be billed past its amount without anyone noticing.
What popdock provides
--
Give a vendor name and a date range and PopdockAI reads that vendor's NetSuite purchase orders and the Ramp purchase orders created in the period. Ramp has no vendor filter, so it keeps orders named after the vendor or whose number matches a NetSuite document, and warns when vendor filtering looks unreliable. It matches by order number, ignoring case and spaces, and lists matched, NetSuite only and Ramp only orders. For matches it shows the Ramp amount, billing and receipt status and total spent, and highlights Ramp orders with spend above the order amount. It never guesses beyond number matches and changes nothing.
Business outcome
---
Operations sees purchase orders missing from either system and any Ramp order spent beyond its amount.
scenario
-
Someone compares NetSuite vendor bills with the Ramp bill list line by line, and bills that never synced slip through. Vendor names are spelled differently between the two systems, which makes a manual search slower still.
What popdock provides
--
Give a vendor name and a date range and PopdockAI reads that vendor's bills in NetSuite and in Ramp. It matches each NetSuite bill to a Ramp bill on invoice number, ignoring spaces and case, and labels a same vendor, same date within 3 days match as probable without guessing further. You get matched bills with approval, payment and sync status, bills only in NetSuite and bills only in Ramp, with counts. NetSuite bill totals are not returned, so it says amounts could not be compared. If a side is empty it reports that instead of calling everything a mismatch, and it changes nothing.
Business outcome
---
Finance finds vendor bills that never synced between NetSuite and Ramp, with the sync and payment status of each match.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.