Ramp + NetSuite is one of the most common combinations Owlery shippers use to pay carriers. Owlery handles the freight side (approving carrier invoices), Ramp handles the money movement (approving and paying bills), and NetSuite stays the system of record for accounting.
The diagram below is the shared picture of the pipeline. Beneath it, “What this means for your accounting team” and “What this means for your IT team” describe the same flow from each team’s perspective.
The flow at a glance
Owlery
Approved invoice
Carrier invoice approved and sent to accounting.
Owlery creates the draft bill
↓
Ramp
1 · Draft Bill→2 · Approved Bill→3 · Payment on bill
Ramp’s native NetSuite sync
↓
NetSuite
Vendor Bill — Phase 1 BILL_SYNC
Bill Payment — Phase 2 BILL_PAYMENT_SYNC, applied to the Vendor Bill
↩️ Back to Owlery: Ramp’s bill.paid webhook marks the original invoice paid.
Who does what. Owlery creates the Ramp draft bill; a person in Ramp approves and pays it. The Vendor Bill and Bill Payment in NetSuite are written by Ramp’s own native NetSuite accounting sync (BILL_SYNC / BILL_PAYMENT_SYNC) — Owlery never writes to NetSuite directly. The only thing that comes back to Owlery is the bill.paid webhook, which marks the invoice paid.
What happens, step by step
Owlery approves the carrier invoice
Once a carrier invoice is approved in Owlery (manually or by your auto-decision rules), Owlery sends it to Ramp as a draft bill. The bill is pre-filled with the carrier (vendor), invoice number, amount, currency, issue date, and due date. The line items and load numbers travel across as memos so your AP team has context.
Your team reviews and approves the bill in Ramp
The draft lands in Ramp as a bill awaiting approval. Nothing is paid yet — this is your control point. Whoever owns AP approves the bill in Ramp exactly as they would any other bill.
Ramp pays the carrier
After approval, Ramp processes the payment (ACH, card, check, etc.). The payment details are attached to the bill in Ramp.
NetSuite gets the Vendor Bill and the payment
Ramp’s built-in NetSuite sync posts the record to NetSuite in two phases:
- Phase 1 — the Vendor Bill. When the bill is approved/synced, Ramp creates a matching Vendor Bill in NetSuite.
- Phase 2 — the payment. When the bill is paid, Ramp creates a Bill Payment in NetSuite and applies it against that Vendor Bill.
The result in NetSuite looks exactly like a normally entered and paid vendor bill. Owlery marks the invoice paid
When Ramp reports the bill as paid, Owlery updates the original invoice to paid, so your freight records and your accounting records stay in agreement — no manual reconciliation.
What you’ll see where
Approval always lives in Ramp. Owlery only creates a draft — money never moves until a person approves the bill in Ramp. This keeps your existing AP controls and approval chains intact.
System responsibilities
Owlery never calls the NetSuite API in this flow. The Vendor Bill and Bill Payment in NetSuite are written by Ramp’s accounting integration, which you configure inside Ramp (subsidiary, vendor mapping, GL/expense account mapping, and the BILL_SYNC / BILL_PAYMENT_SYNC phase settings). If bills aren’t appearing in NetSuite, the fix is in Ramp’s accounting settings, not Owlery.
Sequence
1 — Owlery → Ramp (draft bill creation)
Triggered when an approved invoice is sent to accounting. Owlery resolves the Ramp vendor from the invoice’s broker via a configured Broker → Ramp Vendor mapping, then creates a draft bill.
- Endpoint:
POST https://api.ramp.com/developer/v1/bills/drafts
- Idempotency:
remote_id is set to the Owlery invoice ID, so re-sends don’t create duplicate bills.
- Amounts: Owlery stores money in cents; the draft-bill payload converts to dollars.
- Entity:
entity_id is intentionally omitted — the bill routes to the Ramp vendor’s default entity.
- Payload fields:
vendor_id, invoice_number, invoice_currency, issued_at, due_at, remote_id, memo (load numbers/description), line_items[] { amount, memo }.
On success Owlery stores an accountingSyncs[] subdocument on the invoice keyed on (integrationAuthId, sourceId), where sourceId is Ramp’s draft_bill_id.2 — Ramp → NetSuite (native two-phase sync)
Configured entirely in Ramp’s accounting integration for NetSuite:
BILL_SYNC — pushes the approved Ramp bill to NetSuite as a Vendor Bill. Requires vendor mapping, subsidiary, and GL/expense account mapping in Ramp.BILL_PAYMENT_SYNC — pushes the payment to NetSuite as a Bill Payment / Vendor Payment, applied against the Vendor Bill from phase 1. Requires a mapped payment/clearing account in Ramp.
3 — Ramp → Owlery (paid status webhook)
Ramp fires a bill.paid webhook. Owlery matches it to the invoice on (integrationAuthId, sourceId) and stamps accountingSyncs.paidAt, flipping the Owlery invoice to paid. The write is an atomic idempotent upsert — a retried or duplicate webhook can never create a duplicate or drop an existing sync.Setup checklist
Ramp Developer app + OAuth
Create the Ramp Developer app and connect it in Owlery. Required scopes: bills:write, bills:read, vendors:read, entities:read, accounting:read. Owlery uses the OAuth2 authorization-code + refresh-token flow (redirect URI https://owlery.ai/api/auth/integrations/callback/ramp). See Connect Ramp to Owlery. Broker → Ramp Vendor mapping (in Owlery)
On the Ramp integration card in Owlery, configure the Customized Mapping from each broker profile to its Ramp vendor. Without it, draft-bill creation fails with a “No Ramp vendor is mapped for this broker” error — Owlery never guesses a vendor.
Ramp → NetSuite accounting sync (in Ramp)
In Ramp’s accounting settings, connect NetSuite and enable both the Vendor Bill (BILL_SYNC) and Bill Payment (BILL_PAYMENT_SYNC) phases. Map subsidiary, vendors, and GL/expense + payment accounts. This is Ramp-side configuration and independent of Owlery.
Ensure Ramp is configured to deliver the bill.paid event so Owlery can reconcile paid status back onto the invoice.
Troubleshooting
