# Accept a Tender Source: https://help.owlery.ai/carriers/accept-a-tender How to review, accept, or reject tendered loads from your shippers in Owlery. When a shipper awards you a load, it shows up as a tender in your **Quotes & Tenders** list. Here's how to review the details and respond. **Direct tenders**: Some shippers combine quoting and accepting into a single step. Instead of separate quote and tender workflows, you'll see one form where you fill in Mode, Price, Load Number, and Estimated Stop Dates, then click **Submit**. The process is the same — just fewer round trips. In the left sidebar under **Operations**, click **Quotes & Tenders**. Look for items with a **Tendered** status, then click the row to open the tender drawer. Check the **Details**, **Order Items**, and **Documents** tabs for the full picture — locations, dates, freight info, and any attached files from the shipper. Depending on the shipper's setup, you may need to enter: * **Load Number**: your internal tracking or reference number. * **Price**: confirm or enter the agreed rate. * **Mode**: FTL, LTL, etc. Not every field will appear on every tender — it depends on what the shipper requires. Click **Accept** to confirm the load, or **Reject** if you can't haul it. If the pickup or delivery facility uses Owlery Dock Scheduling, you can book your appointment times directly in Owlery instead of calling or emailing the facility — see [Book an Appointment](/dock-scheduling/book-an-appointment). Facilities that don't use Owlery Dock Scheduling still need to be contacted the usual way. # EDI Onboarding Source: https://help.owlery.ai/carriers/edi-onboarding Configure your carrier EDI connection, generate SFTP credentials, complete testing, and request production activation. You can complete most EDI setup and testing yourself in Owlery. Contact Support only when a required shipper connection is missing or you are ready for production activation. ## Set Up Your Connection **Where to find it:** `Dashboard → EDI Test` Select the shipper under **Owlery EDI Connection**. If the shipper is not listed or its ISA configuration is missing, contact [support@owlery.ai](mailto:support@owlery.ai). Owlery must complete that shipper-side setup before you can test. Under **Carrier EDI Connection**, click **Configure ISA ID**. Enter your **ISA Qualifier** and **ISA ID**, then click **Save**. You can return here and click **Edit** if either value changes. Under **SFTP Setup**, choose **Password** or **Public Key**, then click **Generate Credentials**. Save the connection details shown in Owlery. If password credentials already exist, you can click **Get 1Password Share Link** to retrieve them securely. Use the connection details and directory structure shown in **EDI Test** to connect your translator. Follow the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) for transaction requirements, file handling, identifiers, acknowledgements, and test-versus-production rules. Missing carrier ISA or SFTP setup does not require Support. Complete those items directly in **EDI Test**. ## Complete Guided Testing **Where to find it:** `Dashboard → EDI Test → Test Plans` Choose the shipper and click **Start Test** for the required plan. If **Start Test** is unavailable, follow the message shown in Owlery. It distinguishes steps you can complete yourself from missing shipper-side setup that requires Support. Owlery shows the current test action, load, and sample for each step. Complete only the active step. Owlery validates the transaction and advances the test when it passes. If it fails, review the result and correction hint, update your transaction, and retry the step. Continue until each required plan shows **Passed**. Use the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) as the source of truth for transaction structure and field-level requirements. ## Request Production Activation After every required test plan passes, email [support@owlery.ai](mailto:support@owlery.ai) to request production activation. Owlery verifies the connection and enables live EDI for the carrier-to-shipper relationship. You continue using the connection credentials created in **EDI Test**. Follow the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) for the production transaction requirements. Do not send live EDI until Owlery confirms that the connection is enabled for production. # Edit a Load Number Source: https://help.owlery.ai/carriers/edit-a-load-number How to correct a load number after accepting a tender so it matches the shipment ID on your invoice. The **Load Number** you enter when accepting a tender needs to match the shipment ID you'll use when invoicing. If you entered the wrong number — a typo, the customer's order number, a stale reference, or the wrong load from your TMS — you can update it after the fact from the load itself. Owlery matches invoices to loads by Load Number. If your invoice's shipment ID doesn't match the Load Number on the load, the invoice won't attach to the right shipment and may be rejected or delayed. Go to **Shipments (Loads)** in the left sidebar, find the load, and click the row to open the load drawer. In the top-right of the load drawer, click the **three-dot menu** (⋮) next to the load number. Choose **Edit Load Number** from the dropdown. Type the correct Load Number — the same shipment ID you'll use on your invoice — and confirm. The load updates immediately. Image You should ideally update any Load Number **before** you submit the invoice. Once the number matches, invoicing works the same as any other load — see [Submit an Invoice](/carriers/submit-an-invoice). ## Find Your Load Number `Dashboard → Shipments (Loads)` is the source of truth for your Load Number. Whatever shows there is the value Owlery matches on — for invoices, for POD and document filenames, and for every other lookup. If you're ever unsure what your Load Number is, open [owlery.ai/dashboard/loads](https://owlery.ai/dashboard/loads), find the shipment, and read the Load Number off the load. How that number was set depends on how you took the shipment: * **Accepted manually in the Portal** — it's the value your account manager entered when they accepted the tender. Confirm it on the load. * **Accepted through your API** — Owlery records its own Load Number for the shipment, which may differ from your internal reference. Check `Shipments (Loads)` to see what Owlery used. * **Connected by EDI** — it's the shipment ID Owlery assigns, carried as the shipment ID on your EDI 204 tender and your EDI 210 invoice. ### When the Shipper Enforces a Universal Shipment ID Some shippers turn on **Universal Shipment ID**. When they do, Owlery uses the *shipper's* own shipment ID (from their tender) as the Load Number for both sides, and that number stays fixed for the life of the shipment — updating your PRO or reference numbers won't change it. Use that shared shipment ID exactly as it appears on the load whenever you invoice or name a document. # Choose a Carrier Integration Option Source: https://help.owlery.ai/carriers/integration-options Compare the Carrier Portal, API, and EDI for quotes, tenders, tracking, documents, and invoices. Owlery can meet your team where it already works. Start with the Carrier Portal, connect an API, use EDI, or combine them by workflow. ## Compare Your Options | Workflow | Carrier Portal | API | EDI | | ------------------------------- | ---------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Submit quotes | Enter quotes in Owlery | Send structured quote responses | Not part of the standard carrier EDI flow | | Accept or reject tenders | Respond in **Quotes & Tenders** | Respond to the current tender revision | Respond through your EDI connection | | Respond to load changes | Compare and respond on the existing load | Respond to the new revision on the existing load | Process the revision on the existing load | | Update tracking | Enter stop times and in-transit updates | Send tracking events | Send shipment status updates | | Upload PODs and other documents | Upload from the load | Upload a file to the load | Drop PDFs on SFTP, named by load number, under `documents/{type}/`, or use the Portal or API | | Submit invoices | Create one invoice or upload a CSV | Send structured invoice data | Send freight invoices | | Book dock appointments | Book in Owlery Dock Scheduling | Not part of the carrier API onboarding flow | Not part of the standard carrier EDI flow | ## Carrier Portal The Carrier Portal has no technical implementation. Your team signs in with a work email and handles each workflow in Owlery. Choose the Portal when you: * Manage a lower shipment volume. * Want operations or billing teams to start immediately. * Need a fallback when an automated connection is unavailable. * Need to upload PODs or book dock appointments alongside an EDI connection. Start with the [Carrier Portal overview](/carriers/overview). ## API The API connects Owlery to your TMS or another internal system. Owlery provides credentials and endpoint documentation. Your team maps the data and handles requests and responses. Choose the API when you: * Already integrate with customers through REST APIs. * Need structured quote, tender, tracking, document, or invoice automation. * Want to keep users in your TMS. * Prefer real-time requests over file exchange. Review the [Owlery API reference](https://owlery.ai/open/api), then email [support@owlery.ai](mailto:support@owlery.ai) for credentials and connection setup. ## EDI Choose EDI when you already operate an X12 translator and want a standard file-based connection. Your team configures its carrier ISA ID, generates SFTP credentials, and completes guided certification in `Dashboard → EDI Test`. Continue with [EDI Onboarding](/carriers/edi-onboarding). Use the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) for transaction structure and field-level requirements. ## Combine Options Safely You do not need to automate every workflow at once. For example, you can use EDI for tenders, tracking, and invoices while your billing team uploads PODs in the Carrier Portal. Assign one system of record to each workflow. Do not accept the same tender or submit the same invoice through two channels. For load changes and invoice corrections, reuse the original load and invoice identifiers so Owlery updates the existing record. If you are unsure which option fits, email [support@owlery.ai](mailto:support@owlery.ai) with the workflows you want to automate. # Invite Teammates Source: https://help.owlery.ai/carriers/invite-teammates How to add team members to your carrier account so they can manage loads in Owlery. Need someone else on your team to handle loads for a shipper? You can invite them directly from Owlery. In the left sidebar under **Management**, click [**Invite Team**](https://owlery.ai/dashboard/team-members). Click the shipper row to expand it. You'll see a list of teammates who already have access. Click **Invite To Team**, enter the person's email address, and click **Invite User**. They'll receive an email from [support@owlery.ai](mailto:support@owlery.ai) with a link to sign in. Invitees show as `Pending` until they accept and sign in. Once they do, their status changes to `Active`. Invitees must sign in with the same email address they were invited with. There's no limit to how many teammates you can add per shipper. ## Manage Contact Roles You can manage contact roles separately for each shipper from the same **Invite Team** page. A teammate can have more than one role. | Role | What it is used for | Who to invite | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Account Manager** | The main contact for spot quotes, RFPs, tenders, and load updates. When the shipper has dispute digests turned on, this role also receives a daily list of disputed invoices with amounts, dates, load links, and invoice links. | Whoever owns the day-to-day relationship with this shipper — the person quoting, tendering, and tracking loads. | | **RFP Manager** | Receives RFP requests and coordinates proposals. This role does not receive spot quote, tender, load update, or invoice emails unless the teammate also has another role that receives them. | Whoever puts together bids and manages the proposal process for this shipper. | | **Accounting** | Receives billing, invoice, and payment communications, including disputed invoice digests when enabled by the shipper. After a payment through Owlery clears, this role receives the remittance details, paid-invoice link, and invoice-and-amount CSV. | Anyone who works on invoicing or freight pay for this shipper — your AP/AR contact, biller, or factoring company. | | **IT Team** | Identifies the teammate responsible for technical setup and access coordination. | Whoever handles integration, EDI, or API setup for this shipper. This doesn't have to be someone inside your company — invite a third-party EDI provider, integration partner, or IT contractor if they're the one doing the setup. | Not sure who to invite? Match the role to the *type of work*, not the person's title. For example, if your EDI vendor manages a shipper's EDI/integration setup, invite them directly and assign them the **IT Team** role — they don't need to be an employee of your company. Go to [`Dashboard → Management → Invite Team`](https://owlery.ai/dashboard/team-members) and expand the shipper whose invoice contacts you want to manage. Click **Invite To Team** and enter their email. New teammates start with the **Account Manager** role. Click the teammate's **Role** cell and choose one or more roles. Owlery saves the roles for that shipper relationship. Expand each additional shipper and assign the roles there. Changing a role for one shipper does not change the teammate's role for another shipper. The shipper controls whether disputed invoice digests are turned on. Payment remittance emails are available only when that shipper pays you through Owlery. # Carrier Portal Source: https://help.owlery.ai/carriers/overview Quote, tender, track, and invoice — everything carriers need to manage loads in Owlery. Owlery gives carriers a single place to manage the loads you haul for your shippers — submit bids, accept tenders, update tracking, upload PODs, and send invoices. ## Logging In Owlery recognizes your company by your email domain. There are no accounts to manage and no usernames or passwords to remember. Anyone at your organization with a company email can sign in. * [How to sign into Owlery](/signing-in) * [How to invite teammates to a specific shipper's account](/carriers/invite-teammates) ## What You Can Do Bid on open rate requests from your shippers. Review and accept (or reject) tendered loads. Review a proposed revision on the existing load. Check outstanding tenders and troubleshoot delivery. Correct a load number so it matches the shipment ID on your invoice. Book pickup and delivery times online for facilities using Owlery's Dock Scheduling. Enter arrival and departure times to keep shippers in the loop. Attach PODs and other documents to delivered loads. Invoice shippers manually, in bulk by CSV, or through the API or EDI. Follow invoice status, see why one was disputed, and resubmit corrections. Match payments to invoices when your shipper pays through Owlery. ## Connecting via Integration If your organization has a TMS or integration team, Owlery can automate quoting, tendering, tracking, document exchange, and invoicing through API or EDI. You can start EDI setup yourself from `Dashboard → EDI Test`. Contact [support@owlery.ai](mailto:support@owlery.ai) for API credentials, a missing shipper connection, or EDI production activation. * [Compare the Carrier Portal, API, and EDI](/carriers/integration-options) * [Set up and test an EDI connection](/carriers/edi-onboarding) * [Connect your Tai TMS](/carriers/tai-tms) to Owlery using our out-of-the-box API connection If your organization connects to Owlery via API or EDI, parts of the workflows above may be handled automatically. The guides still cover what each feature does, even if your day-to-day steps look different. *** Stuck on something? Email [support@owlery.ai](mailto:support@owlery.ai) # Remittance Details Source: https://help.owlery.ai/carriers/remittance-details Find remittance details for invoices paid through Owlery. Freight Pay only applies if your shipper is paying through Owlery. If you're set up for it, you'll already have provided your banking details to Owlery in order to be paid — if you haven't, your shipper is paying you directly and remittance details won't appear here. **Where to find it:** `Dashboard → Finances → Invoices` To find remittance details, go to the **Invoices** page. To choose which teammates receive payment remittance emails, see [Manage Contact Roles](/carriers/invite-teammates#manage-contact-roles). ## Where Paid Invoices Appear Invoices that have been paid show up on one of two tabs. Due to banking & payment limitations, invoices may be in either status even once you have received payment. * [**Payment Created**](https://owlery.ai/dashboard/invoices?tab=paymentCreated): payment has been initiated. * [**Paid**](https://owlery.ai/dashboard/invoices?tab=paid): payment has cleared. ## Matching Invoices to Payments Use the **Payment Statement ID** column to see which invoices were included in which payment. Invoices sharing the same Payment Statement ID were paid together. ## Downloading Detailed Remittance Data For more detailed information, download the table as a CSV from the Invoices page. Screenshot 2026 07 17 At 11 11 20 AM # Respond to Load Changes Source: https://help.owlery.ai/carriers/respond-to-load-changes Review and accept or reject a shipper's changes on the existing load without creating a duplicate. **Where to find it:** `Dashboard → Operations → Shipments (Loads)` When a shipper changes an accepted load, Owlery keeps the current load in place and adds a proposed revision for your review. Work from the existing load. Do not create another load or assign a new load number for the proposed change. ## Review the Changes Find the load by its current **Load Number** and open it. A banner says that a load change is waiting for your confirmation. Click **See Proposed Changes** in the banner or open the **Proposed** tab. Owlery shows the previous and proposed values side by side. Only changed fields are emphasized. Review any changes to: * Reference numbers, equipment, items, price, or temperature requirements. * Pickup and delivery locations. * Requested or scheduled dates. * Stop requirements and notes. * Added or removed stops. Click **Accept** to apply the revision to the existing load. Click **Reject** to keep the previous load details. After you accept, the banner clears and Owlery keeps the same load record and Load Number. After you reject, the **Proposed** tab records that the last edit was rejected and the previous details remain active. ## If You Respond Through an Integration Use the same channel that received the change. Treat the update as a revision to the existing load. Do not import it as a new load in your TMS. Follow the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) for the transaction and response requirements. Respond to the new revision for the existing load number. The original tender is revision `0`; each accepted load change uses the revision identified by the API. A stale revision is rejected so an older response cannot overwrite the current proposed change. If the Portal does not show **Accept** or **Reject**, your connection may require the response in your TMS or by EDI. Follow the message shown on the tender instead of responding through both systems. ## If the Change Is Missing or Incorrect * Confirm that you opened the existing Load Number rather than a second record in your TMS. * Check the **History** tab for the latest tender activity. * For EDI, confirm that your system received and processed the revision according to the [EDI Guidelines](https://owlery.ai/open/edi-guidelines). * Ask the shipper to confirm the exact Load Number, what changed, and when they sent it. * If the comparison is unavailable, email [support@owlery.ai](mailto:support@owlery.ai) with the Load Number, shipper, timestamp, and a screenshot. # Submit a Quote Source: https://help.owlery.ai/carriers/submit-a-quote How to find open rate requests and submit bids to your shippers in Owlery. When a shipper sends out a rate request, it shows up in your **Quotes & Tenders** list. Here's how to review the details and submit your bid. Keep an eye on your quote expiration dates. Once a quote expires, you'll need to submit a new one if the request is still open. In the left sidebar under **Operations**, click **Quotes & Tenders**. This shows all open rate requests from your shippers. Click any row to open the details drawer. You'll find: * **Details tab**: pickup and drop-off locations, dates, equipment type, freight info, and any shipper notes. * **Order Items tab**: a breakdown of the shipment by SKU, including quantities, weights, and dimensions. Review everything before submitting your bid. At the bottom of the **Details** tab, fill in: * **Mode**: FTL, LTL, etc. * **Price**: your quoted rate. * **Estimated Stop Dates**: expected pickup and delivery dates. * **Quote Expiration**: how long your bid stays valid. Click **Submit** when you're ready. ## Competitive Alerts If other carriers have bid significantly lower on the same request, you may see an alert prompting you to adjust your price. You can revise and resubmit any time before your quote expires. # Submit an Invoice Source: https://help.owlery.ai/carriers/submit-an-invoice How to invoice shippers in Owlery — manually, in bulk by CSV, or automatically through the API or EDI. There are four ways to get an invoice to your shipper: create it manually from a load, upload a CSV in bulk, submit it through the Owlery API, or send an EDI 210. Choose the option that best fits your workflow. However you submit, the invoice reaches the shipper immediately and starts in **Under Review** status. Track it from `Dashboard → Finances → Invoices` — see [Track and Fix Invoices](/carriers/track-and-fix-invoices). Uploading a PDF is not the same as creating an invoice. Owlery needs structured line-item data to process an invoice — a PDF alone won't do it. Go to **Shipments (Loads)**, find the load, and click the **Invoice** tab in the drawer. Click **Add Line Item** and fill in: * **Category** (required) * **Description** (optional) * **Due Date** (required) * **Total** (required) Repeat for each charge on the load. **Due Date** records the date you're asking to be paid by. Shippers may also apply their own payment terms and track due dates on their side, so the date they work from can differ from the one you enter. Click **Create Invoice**, confirm or enter your **Invoice Number**, and submit. The invoice reaches the shipper immediately and starts in **Under Review** status, where you can track it from **Finances → Invoices**. Go to **Invoices** under **Finances**. Click the dropdown arrow next to the **Upload** button and select **Download Template**. Screenshot 2026 07 14 At 8 30 26 AM Open the template and fill in the required fields: * Invoice Number * PRO/Load Number * Bill to Account * Invoice Date * Shipper and Consignee location info * Line-Item Total Owlery groups rows with the same Invoice Number into one invoice. Use those rows for separate charges or load numbers. To submit separate invoices for the same load, use a different Invoice Number for each invoice. Back in Owlery, click **Upload**, select a **Shipper**, attach your file, and click **Validate CSV**. If there are errors, fix them in your file and resubmit. Once validation passes, click **Submit Invoices**. Invoices reach the shipper immediately and start in **Under Review** status. If your billing system already generates invoice data, you can create invoices programmatically instead of entering them by hand. Invoices are submitted to `POST /api/external/invoices`. The load number you send must match the **Load Number** on the load in Owlery exactly. Confirm the exact value on the load first — see [Find Your Load Number](/carriers/edit-a-load-number#find-your-load-number). If it doesn't match, the invoice won't attach to the right shipment and payment is likely to be delayed — [correct the Load Number](/carriers/edit-a-load-number) if needed. Endpoint details, authentication, and the full field reference: [Owlery API reference](https://owlery.ai/open/api) Reach out to [support@owlery.ai](mailto:support@owlery.ai) for credentials or help getting started. The shipment identifier on your EDI invoice must match the **Load Number** in Owlery exactly — this is the shipment ID Owlery assigns, which you can confirm on the load ([Find Your Load Number](/carriers/edit-a-load-number#find-your-load-number)). If it doesn't match, the invoice may not attach to the load and payment is likely to be delayed. If you entered the wrong Load Number when accepting the tender, update it to unblock invoicing — see [Edit a Load Number](/carriers/edit-a-load-number). If you already submitted the invoice with the wrong shipment identifier, correct it and reuse the same invoice number so Owlery processes the submission as an update. Use the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) for the complete invoice transaction and field requirements. Validate your implementation in `Dashboard → EDI Test`, then see [EDI Onboarding](/carriers/edi-onboarding) for production activation. ## How Owlery Matches Invoices Owlery identifies an invoice by its **Invoice Number** for that shipper and carrier. It does not use the load number to decide whether an invoice is a duplicate. * **Different Invoice Number**: Creates a new invoice, even when another invoice already references the same load. * **Same Invoice Number**: Updates the existing invoice when its status allows changes. The update can replace its charges, totals, dates, references, and linked load numbers. CSV, API, and EDI submissions can therefore create multiple invoices for one load. The manual flow in the load drawer manages one invoice for that load. An invoice can also cover more than one load when the submission channel supports multiple load numbers. In a CSV, use the same Invoice Number on rows with different PRO/Load Numbers to link those loads to one invoice. If you are correcting an invoice or adding a charge to it, reuse the same Invoice Number so Owlery updates that invoice. Use a new Invoice Number only when your billing system treats the charge as a separate invoice. See [Track and Fix Invoices](/carriers/track-and-fix-invoices). ## Correcting an Invoice You can update and resubmit an invoice while it's **Under Review** or **Disputed**, using the same channel you submitted it through. Once it moves to **Approved**, **Payment Created**, or **Paid**, it's locked. See [Track and Fix Invoices](/carriers/track-and-fix-invoices) for the full process. # Connect Tai TMS to Owlery Source: https://help.owlery.ai/carriers/tai-tms Connect your Tai TMS account to Owlery so load statuses, shipment details, and location updates sync automatically. If you use Tai TMS, you can connect it to Owlery so load status updates, shipment details, and location tracking flow in automatically — no manual entry required. The setup has two parts: share your Tai portal URL and login credentials for your customer, then configure three webhook endpoints inside Tai. This is a production-proven integration used by brokers of every size — no sandbox environment or extended testing period required. Once both parts are complete, your customer is live. The role of the Tai user should be the same as the one you would give to your customer to log into Tai. ## Part 1: Share Your Tai Portal URL and Login Credentials Owlery needs three things from your Tai account to establish the connection: Collect the following from your Tai account: * **Tai portal URL**: the web address you use to log into Tai. It always takes the form `yourcompany.taicloud.net`. * **Tai portal username and password**: any login for your customer will do. * **API key**: the API key associated with that Shipper Customer account in Tai. Share the login credentials and the API key using a secure method (e.g. a password manager share link, encrypted message, or your organization's preferred secure channel). The portal URL isn't sensitive, so you can send it alongside — just make sure we get all three. Email [**support@owlery.ai**](mailto:support@owlery.ai) to coordinate handoff if you're unsure how to share them. The Owlery team will configure the connection on their end and let you know when it's ready. At that point, they'll run a test tender and load to verify everything works. You should never send credentials in plain-text email. Use a secure sharing method so your Tai login and API key stay protected. ## Part 2: Set Up Webhooks in Tai Webhooks let Tai push real-time updates to Owlery whenever something changes on a load. You'll need to configure three endpoints in Tai for each shipper. Email [**support@owlery.ai**](mailto:support@owlery.ai) and let them know which shipper you need a webhook token for. Owlery will generate a token specific to that shipper and send it back to you. In your Tai portal, navigate to the webhook configuration for the shipper and add the following three endpoints. Use the API token from Step 1 to authenticate each one. **Status updates** ```text theme={null} https://api.owlery.ai/api/ext/v1/loads/tracking/tai/status ``` **Load details** ```text theme={null} https://api.owlery.ai/api/ext/v1/loads/tracking/tai/detail ``` **Location tracking** ```text theme={null} https://api.owlery.ai/api/ext/v1/loads/tracking/tai/location ``` **Invoices** ```text theme={null} Coming soon... ``` Once the webhooks are saved, coordinate with the Owlery team to run a test tender and load. This confirms that status, detail, and location events are flowing correctly. Each shipper gets its own webhook API token. If you manage multiple shippers in Tai, repeat Part 2 for each one — request a separate token and configure the same endpoints per shipper. ## Quick Reference | What Owlery needs from you | Where to get it | | ------------------------------------------------------------------- | ----------------------------------- | | Tai portal URL (`yourcompany.taicloud.net`) | The address you use to log into Tai | | Tai portal username & password (any role for your Shipper Customer) | Tai | | Tai API key (for that Shipper Customer account) | Tai | | Webhook API token | Request from Owlery Support | | Webhook endpoint | Purpose | | -------------------- | --------------------------------------------------------------------------------- | | `.../tai/status` | Load status changes (picked up, in transit, delivered, etc.) | | `.../tai/detail` | Shipment detail updates | | `.../tai/location` | Real-time location tracking | | Invoices coming soon | Use [another way to submit invoices](/carriers/submit-an-invoice) in the meantime | ## Need Help? If anything isn't working or you're unsure where to find a setting in Tai, email [**support@owlery.ai**](mailto:support@owlery.ai) and the team will walk you through it. # Track and Fix Invoices Source: https://help.owlery.ai/carriers/track-and-fix-invoices Follow your invoice's status, see why it was disputed, and correct and resubmit it. **Where to find it:** `Dashboard → Finances → Invoices` Once you've submitted an invoice, the Invoices page is where you track its status, find out if it was disputed and why, and correct it if needed. To choose which teammates receive disputed invoice digests and payment remittances, see [Manage Contact Roles](/carriers/invite-teammates#manage-contact-roles). ## The Tabs Your Invoices page has five tabs. Each groups invoices by their current status, and the number badge shows how many are in that state. | Tab | What it means | | ------------------- | -------------------------------------------------------------------------------- | | **Under Review** | You've submitted the invoice and the shipper hasn't acted on it yet. | | **Approved** | The shipper approved the invoice for payment. Payment hasn't been initiated yet. | | **Disputed** | The shipper is contesting the invoice. Open it to see the reason. | | **Payment Created** | Payment has been initiated but hasn't fully cleared. | | **Paid** | Payment has cleared. | * To find **paid** invoices, open the **Paid** tab. * To find **disputed** invoices, open the **Disputed** tab. ## What the Table Shows * **Shipper**, **Invoice #**, **Status**, **Loads**, and **Reference #s** (BOL, PO, etc.) * **Invoice date**, **Payment due date**, **Pickup date**, **Delivery date** * **Awarded** (the quoted amount) vs. **Actual** (what you invoiced) and the **Difference** * **Dispute Label** and **Dispute Reason** columns when an invoice is disputed * **Approval Label** and **Approval Reason** columns when an invoice is approved ## Finding Out Why an Invoice Was Disputed Click any invoice on the **Disputed** tab to open its drawer. You'll see the reason in three places: 1. **A red *"Why this invoice is disputed"* alert** at the top of the **Details** tab — this shows the labels the shipper selected and the free-text reason they entered. 2. **The Dispute Reason column** in the invoice table. 3. **The History tab** in the invoice drawer, which shows the full status-change timeline for the invoice. Common auto-dispute labels include **Rate variance** and **Missing POD** — these tell you exactly what needs to be fixed. * **Rate variance** means what you invoiced doesn't match what was awarded. Compare the **Awarded**, **Actual**, and **Difference** columns, then either correct the invoice or add the detail that justifies the charge. * **Missing POD** is fixed on the load, not the invoice. Upload the POD to the load the same way you'd create a manual invoice — open the load under **Shipments (Loads)** and attach the document. See [Upload Proof of Delivery](/carriers/upload-proof-of-delivery). Once the POD is on file, the shipper's rules re-evaluate the invoice. ## If Your Invoice Never Appeared If you submitted an invoice and it isn't on any tab, the usual cause is a load number mismatch. Owlery attaches invoices to loads by **Load Number**, so if the shipment ID on your invoice doesn't match the Load Number on the load, the invoice has nothing to attach to. Confirm the Load Number on the load ([Find Your Load Number](/carriers/edit-a-load-number#find-your-load-number)), correct it if needed, then resubmit. See [Edit a Load Number](/carriers/edit-a-load-number). ## Fixing an Invoice That's Under Review or Disputed You can update and resubmit an invoice as long as it's in **Under Review** or **Disputed**. Once it moves to **Approved**, **Payment Created**, or **Paid**, it's locked — you'll need to contact the shipper to move it back before you can resubmit. Use the same channel you used to submit the invoice originally. In every case, keep the **same invoice number** so Owlery matches your resubmission to the existing invoice. Re-send the EDI 210 with the **same invoice number** and the corrected data. Owlery matches on invoice number and replaces the existing invoice in place — line items, totals, load numbers, dates, and reference numbers are all updated. Re-submit to `POST /api/external/invoices` with the **same invoice number** and the corrected payload. Behavior is identical to EDI — the existing invoice is updated in place. See the [Owlery API reference](https://owlery.ai/open/api) for the full field list. On the **Invoices** page, click **Upload**, select the shipper, attach your corrected CSV, and click **Validate CSV**. * If any invoice number matches an existing **Under Review** or **Disputed** invoice, you'll see a warning that it will be replaced. Proceed to submit. * If any invoice number matches an **Approved**, **Payment Created**, or **Paid** invoice, submission is blocked. Contact the shipper to change the status before re-uploading. Open the invoice from the **Invoices** table. When the status is **Under Review** or **Disputed**, the line items in the drawer are editable — update the totals, line items, or other details and save. ## What Happens After You Resubmit Every resubmission runs through the same flow: 1. **Duplicate detection.** If the resubmission is byte-for-byte identical to what's already on file, Owlery skips the update — nothing to change. 2. **Lock check.** If the invoice is **Approved**, **Payment Created**, or **Paid**, the update is blocked. Otherwise it proceeds. 3. **In-place replacement.** Line items, total, load numbers, invoice date, party info, and reference numbers are updated on the existing invoice. The invoice number and current status stay the same, so a disputed invoice remains on the **Disputed** tab until the shipper's rules re-evaluate it. 4. **Automatic re-evaluation.** The shipper's Auto-Decision Rules run immediately against the corrected data. If your fix clears the issue (e.g., the total is now within their threshold or a missing POD is now on file), the invoice can auto-approve or move back to **Under Review** within seconds. Watch the status on the Invoices page to confirm. 5. **Exceptions refresh.** Rate variance and missing POD are recomputed against the new data. If a person on the shipper's team **manually disputed** the invoice (rather than it being auto-disputed by a rule), resubmitting will update the invoice data but **won't** override their decision — the invoice stays on **Disputed**. Reach out to the shipper directly to resolve. ## What the Shipper Sees vs. What Stays Internal The dispute label and reason the shipper enters are shared with you — that's what powers the red alert and the Dispute Reason column. Internal shipper details are not shared: their accounting tags and GL codes, which teammate approved or disputed the invoice, auto-batch state, and their internal accounting sync records. ## Quick Reference * **Same invoice number = update.** Different invoice number = new invoice. * **A load can have multiple invoices.** Each separate invoice needs a different invoice number. * **Under Review / Disputed = editable.** Approved / Payment Created / Paid = locked. * **Fix and resubmit through the same channel** you used originally. * **Auto-decision runs immediately** on resubmission — no need to wait. * **Invoice missing entirely?** Check the Load Number on the load. # Troubleshoot a Missing Tender Source: https://help.owlery.ai/carriers/troubleshoot-missing-tenders Confirm the shipper tendered, find outstanding tenders, and check with your own IT or EDI team before contacting the shipper or Owlery. **Where to find it:** `Dashboard → Operations → Quotes & Tenders` Owlery is the authoritative record of whether your shipper tendered a shipment to you. When a tender email or integration message appears to be missing, work through the self-service checks below before contacting the shipper — and reach Owlery Support only if those checks confirm the message never arrived. ## Confirm the Shipper Tendered the Shipment Most "missing load" reports are not missing tenders — the notification was delayed, filtered, or the shipment was never tendered to your organization. **Quotes & Tenders** confirms which of these is true without waiting on the shipper. ## Find Outstanding Tenders Sign in with the email address associated with your carrier organization. If a teammate can see the shipper but you cannot, ask them to [invite you](/carriers/invite-teammates). Filter **Status** to **Tendered**. Search for the Owlery ID, Load Number, BOL, PO, or another reference the shipper provided. Open the row and confirm the shipper, locations, dates, and references. If the tender appears here, you can respond even if its notification email did not arrive. If no row appears after clearing your filters, the shipper likely has not tendered the shipment to your organization yet. Confirm the expected pickup date and reference numbers before assuming a message was lost. ## Check the Delivery Channel Check spam and quarantine for the expected time. Ask the shipper to confirm the carrier contact email used for the tender. A missing email does not mean the tender is missing from Owlery. Check **Quotes & Tenders** before asking the shipper to resend it. Clear active search and status filters, then filter to **Tendered** again. Confirm that you signed in with the correct company email and that your organization has access to the shipper. Do not create a second load to work around a missing row. A missing EDI tender is most often an inbound message your own system already received but has not surfaced in your TMS. **Ask your IT or EDI team to confirm whether an inbound tender (EDI 204) or revision covering the shipment already arrived** before you contact the shipper. Have them search your integration logs by the shipper's ISA/GS identifiers, the pickup date, and any BOL, PO, or shipment reference. Owlery sends every tender and revision it holds, so if **Quotes & Tenders** shows the load, the corresponding 204 was transmitted to your endpoint — your team can trace it on their side. Also check for a queued or failed functional acknowledgement (997) that could indicate the message was received but rejected during processing. Follow the [EDI Guidelines](https://owlery.ai/open/edi-guidelines) for file handling, identifiers, and acknowledgements. Process an update as a revision to the existing load, and record the transaction identifier and any validation or acknowledgement error before escalating. Check your request logs for the quote or tender identifier, request time, HTTP status, and response body. Confirm that your credentials are for the expected carrier-to-shipper connection. ## Before Asking the Shipper to Resend Work through these checks in order. Each one resolves most missing-tender reports without a resend: 1. **Search Quotes & Tenders** with filters cleared. If the load appears, respond to it directly — no resend is needed. 2. **For EDI, check with your own IT or EDI team first.** Have them confirm whether the inbound 204 or revision already reached your integration and simply has not surfaced in your TMS. This is the most common cause of a "missing" EDI tender. 3. **Confirm what the shipper actually sent** — an original tender, a load change to an existing tender, or a cancellation. These actions can share the same Load Number, so resending an original tender when the missing message was a change can create duplicate work in your TMS. Only ask the shipper to resend after these checks show the tender is not in Owlery and did not reach your integration. ## When to Contact Owlery Support Contact Owlery only when the checks above confirm the load is not in **Quotes & Tenders** and your IT or EDI team cannot find the inbound message in your integration. Owlery Support cannot create a tender the shipper never sent — that request goes to the shipper. When those conditions are met, email [support@owlery.ai](mailto:support@owlery.ai) with: * Your carrier name and SCAC. * The shipper name. * The Owlery ID, Load Number, and any BOL, PO, or reference number. * The date, time, and time zone when the shipper sent the tender. * Whether you expected email, Carrier Portal, API, or EDI delivery. * The carrier email address or ISA ID used for delivery. * A screenshot of your **Quotes & Tenders** search and filters. * For EDI, the transaction identifier, time received, and any validation or acknowledgement error. * For API, the request timestamp, endpoint, HTTP status, and response body. Owlery can use those identifiers to trace the message without asking the shipper to create a duplicate tender. # Update Shipment Tracking Source: https://help.owlery.ai/carriers/update-shipment-tracking How to enter arrival and departure times and log in-transit updates for your loads in Owlery. Keeping tracking up to date helps your shippers stay informed and reduces check-call volume. Here's how to update your loads as they move. All times are shown in the facility's local time zone. Saved times can be edited but not removed, and actual dates cannot be set in the future. ## Enter Stop Times In the left sidebar, click **Shipments (Loads)** and select a load to open the drawer. Click the **Tracking** tab. You'll see each stop listed with two fields under **Actual**: * **Actual Arrived**: when the driver arrived at the facility. * **Actual Departed**: when the driver left after loading or unloading. Enter the actual arrival and departure times for each stop, then save. * Saving times on the **pickup** stop updates the shipment status to **In Progress**. * Saving times on the **final delivery** stop marks the shipment as **Delivered**. ## Log In-Transit Updates Between stops, you can use the dropdown on the Tracking tab to log additional updates: * **Location Update**: share the driver's current position. * **Delay**: flag that the shipment is running behind. * **Exception**: report an issue (breakdown, weather, detention, etc.). These updates are optional, but they go a long way toward keeping your shipper relationships strong. # Upload Proof of Delivery Source: https://help.owlery.ai/carriers/upload-proof-of-delivery How to attach PODs and other shipping documents to your loads in Owlery. Once a load is delivered, upload the signed proof of delivery (POD) so your shipper has it on file. You can also upload other documents like lumper receipts at any time — you don't need to wait until delivery. In the left sidebar, click **Shipments (Loads)** and find the delivered load. Click it to open the drawer. Click the **Documents** tab inside the load drawer. Drag and drop your file into the upload area, or click to browse. Common POD formats include PDF, PNG, JPG/JPEG, GIF, BMP, WebP, and TIF/TIFF. Maximum file size: 20 MB. In the preview dialog, choose **Proof of Delivery** from the dropdown (or another type if you're uploading a different document), then click **Confirm**. Wait for the **Upload successful** message. The file then appears in the table with **Document Type**, **File Name**, **Created By**, and **Last Modified**. Confirm that **Document Type** says **Proof of Delivery**. Click the filename to make sure the file opens. ## Send PODs over SFTP If you want to automate document delivery and can send files over SFTP, you can drop PODs and other documents onto your Owlery SFTP connection instead of uploading them in the Portal. Owlery attaches each PDF to the matching load automatically. This only requires SFTP access — you don't need an EDI translator or API integration. Name each PDF after the Load Number it belongs to — for example, `37964416.pdf`. This is the part that matters most: Owlery matches the file to your load **only** by the Load Number in the filename, so it has to match the load exactly. Not sure what your Load Number is? Confirm it on the load in [owlery.ai/dashboard/loads](https://owlery.ai/dashboard/loads) — see [Find Your Load Number](/carriers/edit-a-load-number#find-your-load-number). Drop the PDF into the `documents/{type}/` directory for its type. Use the folder name that matches the document — `pod` for a proof of delivery, `bol` for a bill of lading, `invoice`, `lumper`, and so on. The folder name is matched case-insensitively. Only `.pdf` files under a recognized type folder are picked up. A file named `pod.pdf` at the root doesn't count — the type has to come from the folder. Your `.edi` files continue through the normal EDI path. On a single load-number match, Owlery stores the PDF on the load, records it with a source of **SFTP**, and it appears in the load's **Documents** tab. The file moves to your `processed/` folder. If the load number in the filename matches no loads or more than one load, Owlery can't tell which load the document belongs to. The file is moved to your `failed/` folder so it surfaces for review — check the load number in the filename, then re-drop the file. ## Reconcile a Missing-POD List If a shipper sends you a list of loads missing PODs, work through the list by Load Number. Search **Shipments (Loads)** for the Load Number on the list. Confirm the shipper and delivery location before opening it. Open **Documents** and look for a file whose **Document Type** is **Proof of Delivery**. A file with another type, such as **Bill of Lading**, does not satisfy a POD check even if the filename contains "POD." If no POD is present, upload it and select **Proof of Delivery**. Do not upload the same file again when a valid POD already appears. Confirm the filename and **Last Modified** time, then mark that Load Number complete on the list. Repeat for the next load. ## If the Shipper Still Reports a Missing POD * Confirm that the POD is attached to the same Load Number the shipper listed. * Confirm that its **Document Type** is **Proof of Delivery**. * Open the filename to confirm the upload is readable and belongs to that load. * If an invoice was disputed for **Missing POD**, return to the invoice and confirm its status after the shipper's rules re-evaluate it. See [Track and Fix Invoices](/carriers/track-and-fix-invoices#finding-out-why-an-invoice-was-disputed). * If the POD was attached to the wrong load, upload it to the correct load and contact [support@owlery.ai](mailto:support@owlery.ai) with both Load Numbers. You can upload documents at any point in the shipment lifecycle — even before delivery. If you have a lumper receipt or signed BOL from pickup, go ahead and attach it early. # Book an Appointment Source: https://help.owlery.ai/dock-scheduling/book-an-appointment Step-by-step instructions for carriers to book pickup and dropoff appointments in Owlery Dock Scheduling. Follow these steps to book a pickup or dropoff appointment at a facility that uses Owlery Dock Scheduling. ## First-Time Access Visit [https://owlery.ai/auth/signup-for-appointments](https://owlery.ai/auth/signup-for-appointments) and enter your work email. Owlery checks whether your company already uses Owlery: * If it does, Owlery opens the main sign-in page. Follow [Signing In to Owlery](/signing-in). * If it does not, Owlery sends a secure sign-in link to your work email. After you sign in, Owlery opens **Dock Scheduling**. Booking-only users see **Add Appointment** and **Appointments**. If Owlery says your company already has an account, use the main sign-in page instead of waiting for an appointment login email. ## Before You Start * Have the facility name and full order number ready. * The facility must have Owlery Dock Scheduling enabled. * Some facilities require a full order number instead of a partial reference or Load Number. ## Access Dock Scheduling Log in to Owlery and click **Dock Scheduling** in the left sidebar. Open **Add Appointment**. ## Book an Appointment Click the **Facility** dropdown and pick the warehouse where you need to schedule. Only facilities that have enabled Owlery scheduling appear here. If you don't see your facility, reach out to the facility owner and ask them to enable appointment scheduling in Owlery. Select: * **Pickup** or **Dropoff** * **Live** (driver stays with the truck) or **Drop** (trailer drop) The available options change based on what the facility supports. Use the **Order** search field to look up your order by: * Order number * Reference number (PO number, BOL, etc.) * Load number Type at least 3 characters to trigger the search, then select the matching order from the dropdown. If the facility allows standalone booking, Owlery offers an option to continue with an unmatched order number. Review the warning carefully and confirm the facility before continuing. After you select a facility and order, the **Date and Time** section appears. * Pick a date on the calendar. Grayed-out dates are unavailable — the facility is closed, the date is too soon, or the day is already full. * Choose one of the available time slots. **Customize Time** is available to facility operators, not carrier booking users. If no offered time works, contact the facility. If the facility requires it, enter: * **Pallet count**: the number of pallets on this shipment. * **Reefer settings**: minimum and maximum temperature plus the temperature unit, for temperature-controlled loads. Click **Create Appointment**. ## What Happens Next * **Facility auto-confirms**: Your appointment is immediately **Confirmed**. You'll see a success screen with your appointment details. * **Facility requires manual review**: Your appointment goes into **Proposed** status ("Waiting for confirmation"). The facility will review and confirm or adjust the time. You can check the status of any appointment at any time under the **Appointments** tab. To book another appointment, click **Create Another Appointment** on the success screen. ## If a Facility or Order Is Missing * **Facility is missing**: The facility has not enabled booking for your account or appointment type. Contact the facility operator. Once they enable scheduling, it appears automatically. * **Order is missing**: Confirm the selected facility, Pickup or Dropoff, Live or Drop, and the full order number. Some facilities require an exact order-number match. * **Standalone option appears**: Use it only after confirming the order and facility. Owlery records the unmatched number for the facility to review. * **No standalone option appears**: Ask the shipper or facility to make the order available. A matching order appears after their data is added or updated. * **No time slots appear**: Try another available date. Contact the facility if you need an exception. ## Proposed Versus Confirmed | Status | What It Means | What You Should Do | | ------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Proposed** | The facility must review the requested time. | Wait for confirmation and monitor the **Appointments** tab. Do not create another appointment for the same order. | | **Confirmed** | The facility accepted the appointment time or uses auto-confirmation. | Use the confirmed date and time for arrival. | If a **Proposed** appointment remains pending, contact the facility with the facility name, order number, requested time, and appointment status. The facility controls confirmation. ## Required Information Summary | What you need | Details | | ------------- | ---------------------------------------------- | | Facility | Which warehouse you're booking at | | Stop type | Pickup or Dropoff | | Live / Drop | Live load or drop trailer | | Order info | Order number, reference number, or load number | | Date & time | Your requested appointment window | | Pallet count | Required only if the facility asks for it | | Temperature | Min / max temp plus unit (reefer loads only) | ## Escalation Guidance * Contact the facility for a missing facility, missing order, unavailable time, or pending confirmation. * Contact the shipper when the order details or references are wrong. * Email [support@owlery.ai](mailto:support@owlery.ai) for login failures, page errors, or a facility that confirms scheduling is enabled but still does not appear. Include your work email, facility, order number, requested time, and a screenshot. # Overview Source: https://help.owlery.ai/dock-scheduling/overview Book and manage pickup and delivery appointments at Owlery-powered facilities. Dock Scheduling lets you book pickup and dropoff appointment times at warehouses that use Owlery to manage their docks. Instead of calling or emailing the facility, you can see available time slots and submit your request directly through Owlery. Step-by-step instructions for booking pickup and delivery appointments. ## Who can use it Dock Scheduling is available to all Owlery users. What you see depends on your role: * **Carriers and booking-only users**: Two tabs: **Add Appointment** and **Appointments**. * **Facility owners and shippers**: Additional management capabilities on top of the booking flow. See the [Facility Guide](/facilities/overview) for setting up docks and running the schedule. ## Appointment Lifecycle Every appointment moves through the same states, at every facility and no matter who booked it: `Not Scheduled` → `Proposed` → `Confirmed` → `Arrived` → `Loaded` / `Unloaded` → `Departed` | State | What it means | | ------------------------- | ----------------------------------------------------------------------------------- | | **Not Scheduled** | The order exists but has no appointment yet. | | **Proposed** | A time has been requested and is waiting on the facility to approve it. | | **Confirmed** | The facility has accepted the time. The appointment is booked. | | **Arrived** | The driver has reached the facility and checked in. | | **Loaded** / **Unloaded** | The freight has been worked. Pick-ups read **Loaded**; drop-offs read **Unloaded**. | | **Departed** | The truck has left. The appointment is complete. | The first three cover the booking. If the facility auto-confirms, new appointments go straight to **Confirmed**; otherwise they stay in **Proposed** until the facility owner approves them. Facility teams control this with [direct booking capacity](/facilities/dock-appointment-settings#direct-booking-capacity). The last three cover the truck itself, and the facility's team advances them as the day goes. # Block a Dock Slot Source: https://help.owlery.ai/facilities/block-a-dock-slot Reserve one dock for a specific time range so no one can book it, without attaching an order. **Where to find it:** `Dock Scheduling → Add Appointment → Block slot` Blocking a slot reserves one specific dock for one time range — a placeholder with no order, load, or customer attached. Use it for a maintenance window, a trailer that's sitting in the door, or any time you need to hold a door open for something that isn't a booked appointment. The **Block slot** switch only appears when the facility you selected is one your organization operates. ## Create a Block Start a new appointment as you normally would, and select the facility you operate. The order field is replaced by an alert explaining that you're reserving a dock and time without an order. The slot stays reserved until you unblock it or convert it into a real appointment. A block needs all of the following: * **Facility** * **Pickup or dropoff** * **Live or drop** * **A specific dock**, active and able to handle that stop type * **Start and end time** The dock is required here even though it's optional on a normal booking, because the block reserves that physical door. The block appears on the calendar immediately and the slot stops being bookable. Saving is rejected if the dock is already occupied during that window, or if the block would push the facility past its [concurrent appointment capacity](/facilities/dock-appointment-settings#concurrent-appointment-capacity). Blocks count against that cap like any other appointment. Blocks don't send booking confirmation emails, and they skip the reschedule bypasses that apply to owner-created appointments. ## Unblock a Slot On the calendar, a block appears as a clickable **Dock 3 — Blocked** event with the subtitle **Reserved**. The **Blocked Slot** dialog opens, showing the facility, dock, appointment type, and date and time. The placeholder is deleted and the dock and time become bookable again right away. There's no undo — create a new block if you unblocked by mistake. ## Turn a Block Into a Real Appointment If the block was a placeholder for a load you've now confirmed, you can update it in place into a real appointment rather than unblocking and rebooking. You can't apply **Blocked** through the normal appointment status flow — it's rejected, with a prompt to use **Block slot** on the Add Appointment screen instead. ## What Bookers See Owners see blocks as clickable **Dock N — Blocked** events. Carriers and other bookers don't see the block at all — they only see reduced availability for that dock and time, with no reason given. If a carrier needs to know why a door is held, tell them directly. ## Who Can Do This Only the facility's owning organization can block and unblock slots. Owlery admins can place a block on an owner's behalf. **Show Same Order Appointment Action** under `Shipper Settings → Quoting → Dock Scheduling` is unrelated to blocking, even though it sits under a similar heading. ## Related Settings Change hours for a whole date across the facility instead of holding one door. Operating hours, appointment length, and the capacity cap that blocks are checked against. # Set Up Dock Appointment Settings Source: https://help.owlery.ai/facilities/dock-appointment-settings Configure how appointments are scheduled at your facility — timeslots, capacity, booking rules, and notifications. **Where to find it:** `Master Data → Facilities → [your facility] → Settings` Dock appointment settings control how carriers book pickup and delivery appointments at your facility. You'll configure things like operating hours, appointment length, how far in advance someone can book, and whether appointments need your approval. Each facility has separate settings for **Pickup** and **Dropoff** traffic, so you can run different rules for inbound and outbound freight. Your facility profile needs to exist before you can configure appointment settings. If you don't see your facility listed, reach out to Owlery Support. ## Open your facility's settings In the left sidebar under **Master Data**, click **Facilities**. Find your facility in the list and click it to open the detail drawer. In the drawer, click the **Settings** icon on the left-hand side. You'll see tabs for **Pickup** and **Dropoff** — start with whichever direction you want to configure first. ## Configure your appointment settings Work through each section on the form. The settings you see depend on the appointment type you choose. ### Appointment type Pick how carriers book time at your dock: * **By Appointment**: Carriers pick a specific timeslot. You control the slot length and operating hours. * **First Come First Served (FCFS)**: No timeslots. Carriers book a day, and you set a daily cap on how many appointments are allowed. ### Operating hours and days open Set which days your facility accepts appointments and the hours for each day. Each day can be toggled open or closed individually. If your facility runs overnight shifts, check **Closes next day (after midnight)** so the closing time rolls past midnight correctly. These hours repeat every week. To change them on a specific date — a holiday closure, a half day, or a normally-closed Saturday you want to open — use [holiday and closure dates](/facilities/holiday-and-closure-dates). To hold a single dock for a few hours without touching facility hours, [block a dock slot](/facilities/block-a-dock-slot). ### Appointment length *By Appointment mode only.* Choose how long each timeslot is — options range from 15 minutes to 3 hours. Owlery uses this plus your operating hours to calculate how many slots are available each day. Shorter slots mean more appointments per day but tighter scheduling. If you're not sure, start with 1 hour and adjust once you see how traffic flows. ### Daily max appointments *FCFS mode only.* Set the maximum number of appointments allowed per day. If you don't want a cap, choose **No Max Limit**. ### Concurrent appointment capacity Cap how many appointments can run **in parallel** at your facility, regardless of how many timeslots are technically open. The cap applies across pickup and dropoff combined — so if you set it to 3, only 3 trucks total (inbound and outbound) can be on-site at the same time. Use this when your team or dock space is the bottleneck rather than the number of doors. Leave it unset to let every available slot book independently. This setting is rolling out gradually. If you don't see it on your facility yet, reach out to Owlery Support. ### Drop trailer docks Docks reserved for carriers that leave a trailer parked overnight are excluded from normal live-load scheduling, so their slots can't be double-booked. You mark a dock as drop trailer on the [facility profile](/facilities/facility-profile#drop-trailer-docks), not here. ### Direct booking capacity This controls whether appointments are auto-confirmed or need your approval: * **All**: Every appointment is confirmed automatically. Good for low-traffic docks where you don't need to gatekeep. * **None**: Every appointment request goes to your facility for approval before it's confirmed. Use this for high-demand docks where you need full control. * **Some**: Set a specific number of appointments that auto-confirm per day. Once that limit is hit, additional requests require your approval. ### Appointment scheduling restrictions Prevent last-minute bookings by blocking appointments that are too close to today: * **Allow Appointments Any Time**: No restrictions. * **Disable Same Day Appointments**: Carriers can't book for today. * **Disable Same & Next Day Appointments**: Carriers need at least two days' lead time. You can also set a custom number of days if you need a longer buffer. ### Email notifications Choose which appointment statuses trigger an email to your facility contacts. Check the statuses you want notifications for — for example, **Arrived**, **Departed**, or **Loaded/Unloaded**. Appointment confirmation emails also pull content directly from your [facility profile](/facilities/facility-profile): * **Facility notes**: check-in instructions, paperwork requirements, and the facility address are included on every confirmation. * **Facility contacts**: anyone listed as a contact on the facility is automatically included on the email. Keep your facility profile up to date so carriers always get the right instructions and the right people are looped in. ### Driver info collection For inbound (dropoff) appointments, you can require carriers to provide freight details at booking time when the WMS doesn't already have them. When enabled, the **Add Appointment** form prompts the scheduler for: * **Temperature range**: the temperature zone the freight needs (for example, frozen, refrigerated, ambient). * **Pallet count**: the total number of pallets on the load. This is configured per facility and only applies to inbound traffic. Use it when your WMS often has incomplete order data and you want the carrier to fill the gaps before they arrive. Driver info collection is rolling out gradually. If you don't see the toggle on your facility yet, reach out to Owlery Support. # Dock Scheduling Metrics Source: https://help.owlery.ai/facilities/dock-scheduling-metrics What every number on the Dock Scheduling Data dashboard means, how it's calculated, and how to best interpret certain values. **Where to find it:** `Dock Scheduling → Analytics` This dashboard summarizes appointment volume, punctuality, time on site, and booking lead time for your facility. This page explains what each number means. **Seeing `null` values or empty charts?** Most of this dashboard is built from the arrival and departure times your team records at check-in. If those aren't being captured, there's nothing to calculate and the panel shows `null`. * **Needs an arrival time**: On Time %, Late Arrivals, Median Arrival vs Scheduled Start Mins. * **Needs an arrival and a departure time**: Median Arrived to Departed Minutes, and its weekly and hourly breakdowns. * **Works either way**: Appointments and Median Booking Lead Time, which come from booking data. That last group is why you can see a healthy appointment count sitting next to a wall of nulls. If that's your dashboard, the fix isn't here — make sure your team is [checking drivers in](/facilities/driver-check-in) and recording departures. ## See the Appointments Behind Any Number Every chart value, bar, cell, and summary tile on the dashboard is clickable. Click one and a **See these Appointments** button appears — select it to open the raw appointment records that make up that number. This is the fastest way to answer "why is this number so high?" Instead of guessing, click through and look at the actual appointments. It works everywhere: a bar on a weekday chart, a point on a weekly trend line, a shaded cell in the dwell time grid, or a headline tile. Use this before escalating anything unusual. A single surprising cell is often one truck with a missing departure time, and the appointment list will show you that in seconds. ## How Appointments Are Counted The **Appointments** tile counts every appointment booked at your facility inside your date range. | Included | Excluded | | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | | | | Two important things follow from this: * **This is booking demand, not just completed work**: because future appointments and no-shows are included, the total is not a count of trucks that came through your dock. To see completed activity only, set the date filter to end before today. * **Not every appointment can be scored**: a future appointment or a no-show has no arrival time and no departure time. Any metric built on those timestamps quietly skips them, so it covers fewer appointments than the headline total. This is why On Time % multiplied by the appointment total does not give you a count of on-time trucks. The tile counts appointments, not orders. One appointment can carry several order reference numbers. ### Appointments by Week The same count grouped by week. The first and last points nearly always cover **partial weeks** cut off by the edge of your date range, so a dip at either end is usually the date filter, not a real drop in volume. ### Appointments by Day of Week The count split by weekday. These bars add up to the **Appointments** total. ### Appointments Booked by Facility Whether an appointment was created by your team or by the carrier booking themselves. A single bar labelled `true` means every appointment was booked by the facility, and no carriers are self-scheduling. ## Punctuality Metrics ### On Time % The share of arrived appointments where the driver got there at or before their scheduled start time. * **On time**: the driver arrived at or before the scheduled start. * **Late**: the driver arrived after the scheduled start, by any amount. There is no grace period. A driver who arrives two minutes after their slot opens counts as late, which is why this number often looks worse than your team's own sense of how the dock is running. Read it as strict schedule adherence, not as a verdict on your operation. Appointments where nobody arrived are left out of this calculation entirely. ### Late Arrivals The same on-time split drawn as a share-of-total bar. Green is on time, red is late. It is the same information as **On Time %**, shown as a proportion. ### Median Arrival vs Scheduled Start Mins The typical gap, in minutes, between when a driver arrived and when their appointment was meant to start. * **A positive number means late**: `19` means the typical driver arrived 19 minutes after their scheduled start. * **A negative number means early**. Read this together with **On Time %**. On Time % tells you how often drivers miss their slot; this tells you by how much. Most drivers being a few minutes late is a very different problem from drivers turning up hours outside their window, and On Time % alone can't tell those apart. ## Time on Site ### Median Arrived to Departed Minutes The typical time a truck spent at your facility, measured from arrival to departure. Only appointments that recorded **both** an arrival and a departure are included. This is a median, meaning the middle value. Owlery uses the median because a few trucks that sit for many hours would pull an average far above what a normal driver experiences. If you calculate an average yourself from exported data, expect it to come out higher. ### Median Arrived to Departed Mins by Week The same figure grouped by week. As with volume, the first and last points cover partial weeks. ### Median Arrived to Departed Minutes by Hour and Day A grid showing typical time on site for each appointment hour and weekday. Darker shading means longer. Shading doesn't account for how busy a cell is. A cell covering two appointments looks the same as one covering forty, so an unusually dark cell is often a single slow truck or a missing departure time rather than a real backup. Click the cell and check the appointments before acting on it. The **Grand totals** row is the typical value across all appointments in that column. It is not the average of the cells above it, so the two won't match. ## Booking Lead Time ### Median Booking Lead Time The typical time **in hours** between an appointment being booked and its scheduled start. `119` means the typical appointment was booked around five days ahead. The tile stays in hours even when the number runs into the hundreds. ### Median Booking Lead Time by Week The same figure by week. A rising line means carriers are booking further ahead than they used to. ### Appointments by Booking Lead Time (Hours) The full spread of lead times. Bars to the **left of zero** are appointments booked after their own start time had already passed. That's normal: it covers walk-ins entered once the truck was already on site, and appointments added to Owlery after the fact. It isn't a data error. ## Driver Late Reasons The reason a driver gave for arriving outside their window, captured when your team checks them in. See [driver check-in](/facilities/driver-check-in) for how reasons are recorded. If this panel says **No results**, late reason capture isn't switched on for your organization. It does not mean no drivers were late. Contact Owlery Support to have it enabled. ## Common Questions They cover different sets of appointments — see [How Appointments Are Counted](#how-appointments-are-counted). There's no grace period; one minute late counts as late. See the **On Time %** section above. Those are partial weeks clipped by your date filter. See [Appointments by Week](#appointments-by-week). Your facility's local time, as set on the [facility profile](/facilities/facility-profile) — not the timezone of whoever is viewing the dashboard. Click it. See [See the Appointments Behind Any Number](#see-the-appointments-behind-any-number). # Check In a Driver Source: https://help.owlery.ai/facilities/driver-check-in Mark drivers as arrived, capture late reasons, and move appointments through check-in. **Where to find it:** `Dock Scheduling → Appointments` When a driver shows up at your dock, your team moves their appointment from **Confirmed** to **Arrived** to start the check-in. If the driver is late, Owlery will also prompt for a reason so you can track why arrivals slip. ## Mark a driver as arrived From the dock schedule, click the appointment for the driver who just arrived. Change the appointment status from **Confirmed** to **Arrived**. If the driver arrived past their scheduled window, a dialog opens asking why. Pick the closest reason from the dropdown and save. ## Driver late reasons When the late reason dropdown is enabled for your organization, your team can pick from: * **Traffic** * **Delayed at previous stop** * **Breakdown / mechanical issue** * **Got lost** * **Driver HOS compliance** Late reasons are stored on the appointment so you can review trends over time and follow up with carriers whose drivers are consistently late. They roll up into the **Driver Late Reasons** panel on your [dock metrics dashboard](/facilities/dock-scheduling-metrics#driver-late-reasons). Late reason capture is configured at the **organization** level, not per facility. It's rolling out gradually — if your team doesn't see the dropdown when moving an appointment to Arrived, reach out to Owlery Support to have it turned on. # Set Up Your Facility Profile Source: https://help.owlery.ai/facilities/facility-profile Configure your facility's address, contacts, notes, and dock details so the rest of Owlery has what it needs. **Where to find it:** `Master Data → Facilities → [your facility] → Profile` The facility profile is the source of truth for everything Owlery needs to know about a physical site — where it is, who to contact, what carriers should know before arriving, and how its docks are set up. Several other features (confirmation emails, dock scheduling, driver check-in) pull from this profile, so keeping it accurate pays off everywhere. ## Open your facility profile In the left sidebar under **Master Data**, click **Facilities**. Click the facility you want to edit to open the detail drawer. In the drawer, the **Profile** tab is selected by default. ## What to fill in ### Address The street address Owlery uses on appointment confirmation emails and for distance/ETA calculations. ### Facility notes Free-form notes that carriers see on every appointment confirmation email. Use this for things like: * Check-in instructions (which gate, where to park, who to call on arrival) * Paperwork requirements (BOL, packing list, seals) * Anything else a driver needs before they pull in Treat facility notes as your standing instructions to every driver. If you find yourself answering the same question over and over, it probably belongs here. ### Facility contacts The people at your facility responsible for receiving and shipping. Contacts you add here are automatically included on appointment confirmation emails, so add anyone who needs visibility into the day's dock activity (managers, dock leads, shared group inboxes). ### Docks List each dock door at the site and its label or number (for example, `1`–`7`). Dock labels show up throughout the scheduling UI, so use the names your team actually uses on the floor. #### Drop trailer docks Mark a dock as **drop trailer** if a carrier keeps a trailer parked at it (for example, UPS and FedEx trailers that stay overnight). Drop trailer docks are excluded from normal live-load scheduling so the same slot can't be double-booked. Only users with **Admin** or **Owner** roles can edit drop trailer settings. The setting is rolling out gradually — contact Owlery Support if you don't see it on your facility yet. ## Related settings * [Set up dock appointment settings](/facilities/dock-appointment-settings): operating hours, appointment length, booking rules, and notifications. * [Check in a driver](/facilities/driver-check-in): how arrivals and late reasons flow through the dock schedule. # Find an Appointment Source: https://help.owlery.ai/facilities/finding-appointments Filter, search, and navigate the dock calendar to find the appointments you need. **Where to find it:** `Dock Scheduling → Appointments` A busy facility can have hundreds of appointments on the calendar at once. The controls above and around the calendar let you narrow it to the ones you care about, and move between days, weeks, and months. For what an individual appointment block means once you've found it, see [read the appointment calendar](/facilities/reading-the-calendar). ## Choosing What You See Above the calendar are the controls that decide which appointments appear at all: * **Facility**: pick the facility you're managing. Its address appears underneath so you can confirm you're on the right one. * **Dock Number**: narrow the view to a single dock, or leave it empty to see them all. * **Status tabs**: one tab per stage — **Not Scheduled**, **Proposed**, **Confirmed**, **Arrived**, **Loaded/Unloaded**, **Departed** — plus **All**. Each tab shows how many appointments it holds, and a tab with none is grayed out. The row scrolls if it doesn't fit, so **Not Scheduled** may be cut off until you scroll left. * **Search**: find an appointment by its numbers. Jumping to a result never truncates the day it lands on. The header also shows when the calendar last refreshed. Selecting a status tab **fades and desaturates** the appointments that don't match, instead of hiding them, so you keep the surrounding context. ## Moving Around the Calendar * **Left and right chevrons**: step back and forward one period at a time. * **The button between them**: shows the period you're currently viewing — for example, `Aug 2026`, `Aug 2 - Aug 8`, or `Thursday Aug 13`. Click it to jump back to today. * **The icons at the right**: switch views. The one you're in is highlighted. Each view fits a different amount of detail: * **Month view**: shows up to four appointments per day. If a day has more, a **+N more** link takes you to that week. * **Week view**: days start collapsed and show up to five appointments. A **+N more · Expand** control reveals the rest, and a chevron collapses them again. * **Day view**: appointments sit in hourly lanes and are sized by how long they run. All-day appointments and blocked ranges span the whole day. An **Expand** / **Collapse** button controls how much of the day is visible at once. In day view, the header also shows the timezone you're seeing times in, and whether that's the facility's timezone or your own — for example, `PDT · Facility timezone`. ## The Appointments Table A table of the same appointments sits below the calendar, with its own set of columns. It's the faster way to scan a long list or compare several appointments side by side. ## Other Things You'll See * **Loading bar**: a thin progress bar across the top of the calendar while appointments are still loading. * **Empty week**: the message "No events matching the filters can be found in the current week." * **Gray cells in month view**: dates that fall outside the month you're viewing. * **Striped gray blocks**: closures and blocked docks rather than appointments. See [read the appointment calendar](/facilities/reading-the-calendar#blocked-and-closed-ranges). # Set Holiday & Closure Dates Source: https://help.owlery.ai/facilities/holiday-and-closure-dates Override a facility's normal hours on specific dates — close for a holiday, or open a normally-closed day. **Where to find it:** `Master Data → Facilities → [your facility] → Settings → Holiday & Closure Dates` Holiday and closure dates are rules pinned to specific calendar dates. On a date that has an entry, that entry **replaces** your normal weekly operating hours for the whole facility — every customer, both pickup and dropoff, and all docks. Despite the name, an entry doesn't have to close anything. Each entry is a toggle between **Closed all day** and **Custom hours**, and a custom-hours entry can narrow your normal hours, widen them, or open a day you're normally closed — for example, opening a Saturday for a one-off inbound push. Think of the section as "override this date's hours." ## What an Entry Contains Every entry is a date plus one of two behaviors: * **Closed all day**: the facility takes no appointments on that date. * **Custom hours**: the facility is open only during the time windows you set. The default window is 9:00 AM to 5:00 PM. You can add more than one custom window to a single date to model a split day — for example, 6:00 AM to 11:00 AM and 1:00 PM to 6:00 PM for a lunch shutdown. ## Three Ways to Pick a Date ### US Holiday Pick a holiday by name, such as **Thanksgiving Day**. The menu is searchable and multi-select, so it stays open while you add several at once. A holiday can only be added once. Holidays always recur. Owlery re-resolves the actual date each year, so a moving holiday like Thanksgiving (the fourth Thursday of November) stays correct without you touching it. Only US **public** holidays appear in the list. Observances like Mother's Day or Halloween aren't included, and neither are weekend "substitute day" entries. For a company-specific closure — an inventory day, a plant shutdown — use **Pick a specific date** instead. ### Specific Date, One Time A single calendar date that applies once and never repeats. ### Specific Date, Every Year Turn on the **Every year** switch to make the same month and day recur annually — useful for a fixed-date closure like a company anniversary. An **Every year** entry on February 29 only applies in leap years. ## Precedence When Rules Collide More than one rule can land on the same date. The most specific one wins, so you can carve out one exceptional year without deleting a standing rule. | Priority | Entry type | Example | | ----------- | --------------------------- | ------------------------------------------- | | 1 — highest | One-time specific date | Open 8:00 AM–12:00 PM on Dec 24, 2026 only | | 2 | "Every year" recurring date | Closed every Dec 24 | | 3 — lowest | US holiday | Closed on Christmas Eve as a listed holiday | ## Combinations You Can't Save Two rules on the same date will be rejected when they can't both be true: * **Closed all day plus anything else** on the same date is a conflict. * **Overlapping custom windows** on the same date are a conflict. Multiple custom windows that don't overlap are fine — that's how you build a split day. ## How Blocked Dates Affect Booking * **In the booking calendar**: blocked dates and times are greyed out, so no one can select them. * **On submit**: if someone had the page open before you saved the rule, the booking is still rejected, with a message naming the facility, the date, and the reason. * **A full-day closure is absolute**: it blocks the date for everyone, even a customer who has a reserved slot under a customer-specific schedule. Only owners and Owlery admins are exempt. * **A partial window only narrows what was already open**: time that was never in your normal operating hours stays closed, and isn't reported as newly blocked. ## Timezone and List Behavior * **Everything is facility-local**: dates and times are shown and resolved in the facility's own timezone, even when you're viewing from another zone. * **Past one-time dates leave the list**: they disappear once they've passed, but they're still kept in the saved data. * **A holiday name that no longer exists**: if a holiday leaves the catalog, it stops blocking and the date opens back up. The settings page shows a warning asking you to remove the entry. ## What Bookers See Owners see these rules on the dock calendar as non-clickable **Blocked** overlays across the affected date or hours. Carriers and other bookers see neither the overlay nor the reason — the date or timeslot simply isn't available to pick. If you want a carrier to know *why* the dock is closed, tell them directly. ## Who Can Change This Only the facility's owning organization can add, edit, or remove holiday and closure dates. Everyone else sees the section read-only, and only once entries already exist — enough to explain times they can't book, but not to change them. ## Related Settings Your normal weekly operating hours, appointment length, and capacity — the rules these dates override. Hold a single dock for a few hours instead of changing the whole facility's hours. # Facility Guide Source: https://help.owlery.ai/facilities/overview Everything a facility team needs to set up their docks in Owlery and run the schedule day to day. **Where to find it:** `Master Data → Facilities` If you run a warehouse or distribution center, Owlery handles the dock: carriers request appointment times against the hours and rules you set, and your team works the resulting schedule from a single calendar. This guide is split into the work you do once and the work you do every day. ## Set Up Your Facility Start here when you're onboarding a site, or whenever your hours or dock layout change. Address, contacts, driver instructions, and your dock doors. Operating hours, slot length, capacity, and who needs your approval to book. Override normal hours on specific dates. Configure the facility profile first. Appointment settings, confirmation emails, and driver check-in all read from it. ## Run the Dock The day-to-day work once appointments start arriving. What each appointment block shows, and what its colors and icons mean. Filter by facility, dock, and status, search, and switch between views. Hold one door for a maintenance window or a parked trailer. Mark drivers arrived and capture late reasons. ## The Appointment Lifecycle Every appointment at your facility moves through the same six states, from `Not Scheduled` to `Departed`. See [the appointment lifecycle](/dock-scheduling/overview#appointment-lifecycle) for what each state means. Two parts of it are yours to control. Whether a request lands on **Confirmed** straight away or waits on **Proposed** for someone at your facility to approve it depends on your [direct booking capacity](/facilities/dock-appointment-settings#direct-booking-capacity). And once a driver arrives, your team advances the appointment through the remaining states as the day goes. The calendar encodes both halves at once — the block's fill color tracks the booking, and its left stripe tracks the equipment. See [read the appointment calendar](/facilities/reading-the-calendar#reading-the-colors) for the full color key. ## Connect Your WMS If your warehouse management system is supported, inbound receivers and outbound orders can sync into Owlery automatically instead of being entered by hand. Currently available for Extensiv (3PL Central). ## Need Help? Several facility features roll out gradually, so a setting described here may not be visible on your site yet. If something's missing — or you need a facility added — reach out to Owlery Support. # Read the Appointment Calendar Source: https://help.owlery.ai/facilities/reading-the-calendar How to read the dock calendar: what each appointment block shows, and what its colors and icons mean. **Where to find it:** `Dock Scheduling → Appointments` Every appointment at your facility appears on the calendar as a colored block. Once you know what its text, colors, and icons mean, you can read the state of your whole dock at a glance. This page covers reading an individual appointment. To filter the calendar, search it, or switch between month, week, and day views, see [find an appointment](/facilities/finding-appointments). ## What an Appointment Shows Each block holds three pieces of text: * **Top line (bold)**: the order and reference numbers. Owlery lists the requested order numbers first, then the load number, then the load's reference numbers, then reference numbers from any linked orders. Duplicates are removed, and a long list is cut off with an ellipsis — hover to see all of it. * **Bottom left**: the start time in 24-hour format, followed by the timezone it's shown in, like `13:30 MDT`. All-day appointments don't show a time. * **Bottom right**: the customer name. When your own organization is the customer, Owlery shows the shipper or supplier from the linked order instead. Two icons can appear on the block itself: * **A direction arrow**: sits to the left of the order numbers. An arrow pointing in means inbound — a drop-off at your facility. An arrow pointing out means outbound — a pick-up from your facility. * **A red error icon**: appears in the top-right corner when the appointment has at least one unresolved exception. These are the same exceptions you'd see on the **Exceptions** tab. ## Reading the Colors Each appointment carries two colors: the fill, and a thicker stripe down its left edge. Between them they trace the single path every appointment moves through, with the fill covering the first half ([the booking](/dock-scheduling/overview#appointment-lifecycle)) and the stripe covering the second (the truck). ### The Fill: Where the Booking Stands * **Red**: **Not Scheduled**, or an **Unknown** state. * **Amber**: **Proposed**, and waiting on someone to confirm it. * **Green**: **Confirmed**. The fill color is also used for the block's text and a thin border, so it's easy to spot even on a busy day. ### The Left Stripe: Where the Truck Is * **Gray**: **Not Arrived**. * **Orange**: **Arrived** and on site. * **Blue**: being **Loaded** or **Unloaded**. * **Green**: **Departed**. ### Reading Them Together Once an appointment turns green, the fill has done its job and stops changing — from there you watch the stripe. So green with a gray stripe means confirmed, but nobody has arrived yet. Green with a blue stripe means the truck is at the dock right now. Green with a green stripe means it's finished and gone. | What you see | Where it is on the path | | ------------------ | ------------------------ | | Red fill | Not Scheduled or Unknown | | Amber fill | Proposed | | Green fill | Confirmed | | Gray left stripe | Not Arrived | | Orange left stripe | Arrived | | Blue left stripe | Loaded or Unloaded | | Green left stripe | Departed | Scan for red and amber first. Those appointments haven't cleared booking yet, so they're the ones that need someone to act before a truck shows up. For more on the stages themselves, see [the appointment lifecycle](/dock-scheduling/overview#appointment-lifecycle). ## Getting More Detail Hovering over an appointment opens a tooltip with a quick summary: * The order and reference numbers, in bold and untruncated. * **Customer**: the customer name. * The appointment time. * **Appointment status**: with a colored dot matching the fill. * **Equipment status**: with a colored dot matching the left stripe. * The direction of the stop, with an icon. The equipment status wording follows the type of stop. A pick-up reads **Equipment Loaded**, and a drop-off reads **Equipment Unloaded**. Clicking an appointment opens a drawer with its full details. Blocked and closed ranges aren't appointments, so they can't be clicked. ## Blocked and Closed Ranges Not every block on the calendar is an appointment. **Striped gray blocks** mark times your facility isn't taking trucks, labeled with the facility name and either **Closed** or **Blocked**. A full-day closure reads **Closed all day**; a partial block shows the blocked time window instead. These aren't clickable. Hold one door for a maintenance window or a parked trailer. Override the facility's hours on a specific date. # Extensiv (3PL Central) Source: https://help.owlery.ai/facilities/wms-integrations/extensiv Request Extensiv API access for your warehouse so inbound receivers and outbound orders sync into Owlery automatically. If your warehouse runs Extensiv (formerly 3PL Central), Owlery can read your inbound receivers and outbound orders directly, so appointments and shipment details line up with what's already in your WMS — no manual imports and no CSV uploads. API access is granted by Extensiv, not by Owlery. You submit one request form to Extensiv's professional services team, they issue the credentials, and the connection is built from there. **Would you rather we walk you through it?** Most warehouses set this up on a short screen share with our team. Email [support@owlery.ai](mailto:support@owlery.ai) and we'll arrange one. The steps below are here if you'd prefer to work through it yourself. ## What This Setup Does Not Involve * **No development work**: Owlery uses Extensiv's standard REST API. There is nothing to build. * **No software to install**: nothing is added to your 3PL Warehouse Manager account. * **No data exports**: Owlery reads your account directly. You never assemble spreadsheets of sample records for us. * **No ongoing maintenance**: Owlery refreshes its access token automatically every hour. Once access is granted, it keeps working. ## Before You Start The request form asks for two things you'll need to collect first. ### 1. Your Account TPL Number In the Support Portal, go to **Account** and find the **Account Information** section. Your TPL number is listed there. ### 2. A Dedicated Integration User Integrations with Extensiv require its own user account. In the Support Portal, select **Users** in the left sidebar, click **Create User**, and fill it in: | Field | What to enter | | ---------- | -------------------------------------- | | First name | `Owlery` | | Last name | `Developers` | | Email | `developers+yourcompanyname@owlery.ai` | | User type | 3PL user | | Job title | `IT`, or `Dock Scheduling Integration` | | Role | Full access, or `cust6` | Which role you assign depends on which version of Extensiv / 3PL Central your account is on — older versions use `cust6`, newer ones use a full access role. If only one of the two is available to you, that's the one. Replace `yourcompanyname` with your own warehouse's name — for example, `developers+acmelogistics@owlery.ai`. All of these reach the same Owlery inbox, but the tag tells us which account a message belongs to. Save the user and note its **UserID**. The API request form asks for it. ## Submitting the Request Form Extensiv's professional services team handles API access requests through a single form. Fill this out once you have your TPL number and your integration UserID. Most of it is your own contact information. These are the fields worth calling out: | Field | What to enter | | ------------------------------------ | ------------------------------------------------------------------------------------------ | | TPL ID | Your Account TPL number, from `Support Portal → Account` | | Your Customer's Name | `All Customers` | | Customer ID in 3PL Warehouse Manager | `0` *(this means all customers)* | | API connection | **External API** | | Developer name | `Owlery` | | Developer phone | `(510) 545-9146` | | Developer email | `developers+yourcompanyname@owlery.ai` (the same address you used on the integration user) | | Login | The UserID of the integration user you created | | Platform integrating | Select **Other**, then write in `Owlery` | | Notes | Optional. You can write that you're using Owlery for dock scheduling. | ## What Happens Next Extensiv's professional services team reviews the request and issues the API credentials. If those come back to you rather than to us, forward them to [support@owlery.ai](mailto:support@owlery.ai). We verify the connection and start the first sync. Ask for Production credentials rather than sandbox. Owlery works from your real records, so your team can check the sync against orders it already recognizes. ## What Owlery Syncs Once access is in place, syncing runs on its own. Each cycle pulls only the records created or changed since the last run, so the connection stays incredibly light on your Extensiv instance. We read these two main data types, along with related objects so your dock operations has full visibility into what is coming and going (locations, line items, and PO numbers/reference numbers). * **Inbound Receivers**: Receivers are Extensiv's inbound shipments. We read these to validate appointments for your inbound shipments. * **Outbound Orders**: Outbound Orders are Extensiv's outbound shipments. We read these to validate appointments for your outbound shipments. ## Keeping the Connection Healthy Owlery is built to stay well within Extensiv's API limits and to avoid unnecessary traffic against your instance: * **Automatic token refresh**: Owlery requests an access token and refreshes it every hour. There is nothing for your team to renew or rotate. * **Throttled requests**: Owlery caps its own request rate to stay inside Extensiv's limits. * **Fewer round trips**: line items come back inline with the list request instead of one call per record. * **Incremental sync**: every cycle filters by last modified date, so unchanged records are never re-fetched. ## Technical Reference Everything below is handled by Owlery. It's here for teams who want to see exactly what the integration touches. Owlery requests an access token from Extensiv's token endpoint and refreshes it hourly. All subsequent calls use that token. ```text theme={null} POST AuthServer/api/Token ``` | Purpose | Endpoint | | -------------------------------------------------------------------- | ------------------------------------- | | List receivers (paginated; filtered by date, customer, and facility) | `GET inventory/receivers` | | Get a single receiver | `GET inventory/receivers/{id}` | | Get line items for a receiver | `GET inventory/receivers/{id}/items` | | Create a receiver (ASN) | `POST inventory/receivers` | | List orders (paginated; filtered by date, customer, and facility) | `GET orders` | | Get a single order | `GET orders/{id}` | | Get line items for an order | `GET orders/{id}/items` | | Create an outbound order | `POST orders` | | List active customers | `GET customers` | | List facilities | `GET properties/facilities` | | Get facility location details | `GET properties/facilities/locations` | * Base URL: `secure-wms.com` * Incremental sync filters on `LastModifiedDate`. * List requests pass `Detail=ReceiveItems` or `Detail=OrderItems` to return line items inline. * Owlery throttles its own requests to roughly 5 per second. ## Getting Help Not sure whether you have Support Portal access, or would rather we run the setup with you? Email [support@owlery.ai](mailto:support@owlery.ai). ## Related Settings * [Set up your facility profile](/facilities/facility-profile): Owlery maps your Extensiv facilities to these sites, so keep addresses and dock details current. * [Set up dock appointment settings](/facilities/dock-appointment-settings): operating hours, appointment length, booking rules, and notifications. # Invite Team Members Source: https://help.owlery.ai/inviting-team-members Invite teammates on other email domains, and fix sign-ins where someone can't see the data they expect. Owlery matches people to an organization by their email domain. If someone signs up with a domain that doesn't match your organization, their account won't link to your team automatically — so invite them before their first login. Invite the person **before** they sign in for the first time. If they log in first on a domain that doesn't match your organization, they'll land in an account with no data and need help getting moved. ## Who to Invite, and Where The right page depends on your role and who you're adding. | You are a... | You want to add... | Go to | | ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | | Carrier | Anyone on your team, including a different email domain | [**Invite Team**](https://owlery.ai/dashboard/team-members) | | Shipper | Someone at one of your carriers, on a different email domain | [**Integrations**](https://owlery.ai/dashboard/integrations) | | Shipper | A colleague at your own company on a different email domain | [**Users**](https://owlery.ai/dashboard/users) | In every case the person receives an email invite from Owlery. They must use that invite link to sign in the first time — signing in directly instead of through the invite is what leaves the account unlinked. Invitees must sign in with the same email address the invite was sent to. An invite to `name@example.com` won't work if they sign in as `name@other.com`. ## Invite a Teammate as a Carrier Go to [**Invite Team**](https://owlery.ai/dashboard/team-members) in the left sidebar under **Management**, expand the shipper, and click **Invite To Team**. Any email domain is fine. For the full walkthrough, contact roles, and what each role receives, see [Invite Teammates](/carriers/invite-teammates). ## Invite Someone as a Shipper Go to [`Dashboard → Users`](https://owlery.ai/dashboard/users) and send the invite from there, even if their email is on a different domain than yours. Go to [`Dashboard → Integrations`](https://owlery.ai/dashboard/integrations), open the carrier, and add the person there. This keeps them attached to that carrier rather than to your own organization. ## Using More Than One Email Domain Each Owlery organization is mapped to a single email domain, and Owlery can't add extra domains to an existing organization. If your company uses more than one — after an acquisition or a rebrand, for example — invite those people individually using the table above. **Subsidiary mapping.** If parts of your business need to run as separate organizations on their own domains while still sharing data between them, Owlery supports this for enterprise customers. Email [support@owlery.ai](mailto:support@owlery.ai) with your organization name and the domains involved. ## Troubleshooting This almost always means they signed in with an email domain that doesn't match your organization, so their account was never linked to your team. To fix it: 1. Confirm which email address they actually used to sign in. 2. Send them an invite from the right page for your role — see [Who to Invite, and Where](#who-to-invite-and-where) above. 3. Have them open the invite email and sign in through that link. If they still don't see your data after accepting the invite, [contact Owlery support](/shippers/need-help) with the person's email address and your organization name. Ask them to check their spam or quarantine folder for a message from [support@owlery.ai](mailto:support@owlery.ai). Company email security tools can also rewrite or block the link — if that happens, they can copy the link and paste it into their browser instead of clicking it. See [Signing In](/signing-in) for more. Invitees stay `Pending` until they accept and sign in for the first time. Once they do, the status changes to `Active`. # Managing Contract Rates Source: https://help.owlery.ai/shippers/adding-contract-rates Add contract rates manually or by CSV upload, then edit, bulk-update, or delete them. ## Adding Contract Rates There are two ways: one at a time in the dialog, or in bulk by CSV upload. Click the **+** icon in the toolbar. This opens a dialog titled **Add Contract Rate** (or **Edit Contract Rate** if you're editing an existing one). Here's what you fill in: * **Carrier** *(required)*: Search and select the carrier. * **Fuel Charge Table** *(optional)*: Link a fuel surcharge schedule. The dropdown shows each schedule's name, type, and number of tiers. Leave blank for an "All In" rate. * **Shipment Mode**: Truck, Rail, etc. * **TL / LTL**: Full Truckload or Less Than Truckload. Changes the pricing section below. * **Dry Van / Reefer**: Equipment type. Selecting Reefer reveals temperature fields. * **Solo / Team** *(TL only)*: Whether the rate is for a solo driver or a team. * **LTL Pricing** *(LTL only)*: Choose **Pallets** (quantity-based) or **Weight** (weight-based) pricing. * **Currency**: USD, CAD, or MXN. * **Rate** *(TL with fixed stops)*: A single line-haul price for the lane. * **Rate with accessorials** toggle *(TL with fixed stops)*: When enabled, the Rate field splits into **Line Haul** (base charge) and **Stop Charge** fields. You can add up to 6 stop charges, each with an editable description. The total is shown at the bottom. * **Use dropoff candidate pricing** checkbox *(TL only, in dialog header)*: Enables per-stop-count pricing with stop whitelists and tiered ranges. Useful for lanes where carriers charge different rates based on how many stops the load has. Then below the pricing section, you define each stop on the lane. Each stop has: * A **Stop Address Type** (accessible via the ⋮ menu next to the stop label): * **Select an address**: Match by specific facility/facilities. This is the default and most common. * **Zip Code/Range**: Match any location within a zip code or zip code range. * **Input any address**: Match by specific street address(es). * **Any location**: Match any location. Used for catch-all or variable stops. * **Live** or **Drop**: Whether the driver waits or can drop the trailer. * **Transit Min Hours** / **Transit Max Hours**: Estimated transit time from the previous stop. * **Select Facility or Zipcode**: The actual facility or location picker (shown for "Select an address" type). * Add/remove stops using the buttons at the bottom of the list. Additional settings further down: * **Total Distance**: Manually enter the lane's distance in miles (optional). * **Open-ended stop** checkbox: For lanes with a variable number of beyond the defined stops. * **Set max stop count**: Cap the number of stops this rate matches. If **Reefer** is selected, temperature fields appear: * **Min temp** / **Max temp**: Temperature range in °F. * **Precooling temp**: Pre-cool temperature in °F. * **Continuous** / **Cycle-Sentry**: Cooling mode. Click the **Upload** button (split button with dropdown): * **Upload**: Opens the **Upload Contract Rate** dialog where you drag-and-drop a CSV file. On the next step, you'll see a **Confirm Upload Contract Rate** screen with two tabs: * **Validation**: Shows how many rows passed validation, contract info (carrier, fuel schedule, dates), and duplicate handling options. If duplicates are found, you pick an **Update Strategy**: * **Add as new contracts**: Create new rates, leave existing ones untouched. * **Update matching contracts**: Overwrite existing rates that match the same criteria. * **Add new and expire old contracts**: Create new rates and expire matching existing ones. * **CSV Preview**: See the raw CSV data before confirming. * **Download Template**: Downloads a CSV template pre-populated with your existing rates from the current tab. Edit in Excel/Sheets and re-upload. Fastest way to bulk-edit or bulk-add. ## Editing and Managing Rates Each row has a ⋮ menu with: * **Edit**: Opens the **Edit Contract Rate** dialog with all the same fields described above. * **Edit Contract Dates**: Set or change the activation and expiration dates. These determine which tab the rate appears in. * **Delete**: Permanently removes the rate. In the detail drawer header, there are icon buttons for the same actions plus: * **Convert to Routing Guide** (up-arrow icon): Admin only. Promotes the rate to a routing guide entry. ### Bulk Operations * **Bulk Edit Contract Dates** (calendar icon): Click to enter selection mode, check rows, then click **Continue Edit** to set/clear activation and expiration dates for all selected rates. * **Bulk Delete** (trash icon): Click to enter selection mode, check rows, then click **Continue Delete** to confirm. Press the ✕ button to exit bulk mode without changes. # AI Assistants & MCP Source: https://help.owlery.ai/shippers/ai-assistants-and-mcp Owlery does not currently offer a Claude connector or MCP server. Here's what exists today and what's in development. **Owlery does not currently offer a Claude connector or an MCP server.** If you've been asked to connect Owlery to Claude, ChatGPT, Copilot, or an in-house agent, there is no first-party connector to install today. If what you're after is an AI assistant that can answer questions about your freight, see [Hootie](/shippers/hootie) — our AI teammate for Slack, Teams, and email, currently in beta for customers on request. ### What this means today * There is no Owlery MCP server to add to Claude, Claude Code, or any other MCP client and Owlery does not appear in the connector directories of Claude, ChatGPT, or Microsoft Copilot. * Hootie is Owlery's own assistant and is added through Slack or Teams — not through an MCP client. If you find something claiming to be an official Owlery connector for an AI assistant, it isn't ours — please let us know at [support@owlery.ai](mailto:support@owlery.ai). ### What you can do in the meantime Two options, depending on what you need: **Ask about the Hootie beta.** If the goal is "let people ask questions about our freight in the tools they already use," [Hootie](/shippers/hootie) covers that in Slack, Teams, and email — without you building or maintaining anything. It's in beta and available to customers on request. **Build on the Open API.** If you need Owlery data inside your own assistant or agent, our [Open API](https://owlery.ai/open/api) is the supported path, and several customers have used it as the foundation for internal tooling. A few things worth knowing before you go down that road: * You'll be responsible for the connection, its credentials, and anything the assistant does with the data it reads. * Treat API credentials the way you'd treat any other production secret — an assistant with a saved key inherits everything that key can do. * Freight data often contains customer names, addresses, and rates. Check with whoever owns data policy at your company before routing it through a third-party model. ### What's in development Our AI roadmap is actively in development. Hootie is the first thing to ship from it, and native support for third-party AI clients — including MCP — is part of what we're evaluating next. We're not announcing dates or specific clients yet. ### Tell us what you'd want If you have a specific use case in mind — a question you'd want to ask an assistant about your loads, a workflow you'd want it to handle — that feedback genuinely shapes what we build first. Email [support@owlery.ai](mailto:support@owlery.ai) and tell us what you'd use it for. # Add a Carrier or Broker Source: https://help.owlery.ai/shippers/carrier-portal/add-a-carrier-or-broker Add a carrier or broker to Owlery for quoting, tendering, and Carrier Portal access. **Where to find it:** `Dashboard → Integrations` You can add as many carriers and brokers as you need. The same flow covers both a full data integration and simple Carrier Portal access. The green **Add Integration** button is in the top right. Many carriers and brokers have a predefined integration — choose it if yours is listed, since it enables real-time data exchange. If it isn't listed, choose **Carrier Portal**, which works for anyone. Confirm the account manager's name, and leave **Also add this broker to quoting integrations when Owlery can match their brokerage** ticked. This makes them available to quote without any extra setup — see [Preferred Brokers](/shippers/quoting#preferred-brokers). ## What Happens Next * **Owlery already knows this carrier or broker**: they're available for quoting and tendering straight away. * **Owlery doesn't know them yet**: they get an email invite to join your network. They confirm their MC/DOT number during onboarding, and then they're available to quote and tender. # Add LTL Carrier Accounts Source: https://help.owlery.ai/shippers/carrier-portal/add-ltl-carrier-accounts How to add LTL carrier accounts to an existing carrier integration in Owlery. If you already have an LTL carrier integration set up, you can add carrier accounts scoped to specific addresses or zip codes without creating a new integration. Visit [owlery.ai/dashboard/integrations](https://owlery.ai/dashboard/integrations). Find the carrier integration you want to add an account to (for example, **R\&L**), and click the **3 dots (⋯)** next to it. Select **Manage Accounts** from the menu. Enter the account number for the corresponding address or zip code. # Cin7 Core Integration Source: https://help.owlery.ai/shippers/cin7-core Connect once, confirm the recommendation, and let Owlery handle the details. Owlery connects Cin7 Core, formerly DEAR Inventory, to your freight operation. We synchronize sales, advanced purchases, stock transfers, products, and facilities, then configure the date write-back workflows that fit your process. Cin7 Core and Cin7 Omni are separate products with different APIs and Owlery connectors. This guide covers the production Cin7 Core connector. **Where to find it:** `Settings → Integrations` ## Three parts of the integration Synchronize orders, products, facilities, contacts, dates, quantities, prices, units, and packaging. Optionally update sale, purchase, and stock-transfer dates from Owlery shipment events. Review the available order scope, source-channel filters, customer filters, and splitting controls. Most teams start with read-only synchronization. Date write-back can be introduced after your team validates the inbound records. ## Getting started Your administrator provides a Cin7 Core API account ID and application key. Owlery validates access before synchronization begins. Share representative sale, advanced-purchase, or stock-transfer numbers. Owlery learns your locations, units, fulfillment patterns, and exceptions from the records themselves. Owlery presents the recommended order scope, mappings, filters, splitting behavior, and optional write-back. Your team confirms it matches how you operate. Owlery validates normal and exception scenarios, starts synchronization, and monitors the first records and any enabled write-back. We maintain the configuration as your Cin7 Core workflow changes. Need help planning your Cin7 Core connection? Email [support@owlery.ai](mailto:support@owlery.ai). # Cin7 Core Configuration Reference Source: https://help.owlery.ai/shippers/cin7-core/configuration Order scope, filters, splitting, item mapping, and date write-back controls. This reference summarizes the controls available for Cin7 Core. Owlery reviews your account, recommends the relevant settings, and maintains the configuration. You do not need to configure these settings yourself. Your team confirms Owlery's recommendation. | Area | Available controls | | --------------------------- | ---------------------------------------------------------------------------------------- | | Order scope | Enable or disable sales, purchase, and transfer synchronization independently | | Sales source channels | Synchronize all sales or allow only configured `SourceChannel` values | | Customer-name filtering | Exclude sales whose customer name begins with a configured prefix | | Customer identity filtering | Exclude records associated with selected customer source IDs | | Fulfillment splitting | Split a sale into linked orders by pick location, or keep it whole | | Status handling | Map sale, purchase, and transfer lifecycles to Owlery states | | Units and packaging | Interpret product units, weights, and dimensions for freight planning | | Exact lookup | Find and synchronize a specific sale, purchase, or transfer reference | | Date write-back | Update sales `ShipBy`, purchase `RequiredBy`, and transfer departure or completion dates | ## Source-channel filtering A source-channel allowlist applies only to sales. Matching is case-insensitive. Sales without a source channel are excluded when an allowlist is active. Purchases and stock transfers are unaffected. ## Fulfillment-location splitting Owlery can keep each sale as one order or split it by the fulfillment pick location. The integration reconciles changed assignments across later syncs so removed, added, and restored location splits do not create uncontrolled duplicates. ## Authentication details Owlery needs a Cin7 Core API account ID and application key. Credentials must allow the selected sales, advanced-purchase, stock-transfer, product, location, customer, supplier, and optional write operations. # Reading Data from Cin7 Core Source: https://help.owlery.ai/shippers/cin7-core/reading-data How Owlery synchronizes Cin7 Core orders, products, facilities, and fulfillment activity. Once Cin7 Core credentials are connected, Owlery retrieves paginated records and converts them into the stops, partners, items, dates, quantities, prices, and statuses used by your freight workflow. Owlery discovers your locations, products, fulfillment patterns, and exceptions from the connected account. Your team confirms the recommended mapping rather than preparing a field specification. ## Orders | Cin7 Core record | How Owlery uses it | | ----------------- | ----------------------------------------------------------------------------------- | | Sale | Creates a customer shipment from the shipping address, fulfillment, and order lines | | Advanced Purchase | Creates a supplier shipment from supplier, receiving, and order data | | Stock Transfer | Creates an internal movement between source and destination locations | Owlery can synchronize source IDs, order numbers, statuses, notes, references, customer or supplier contacts, facilities, requested and actual dates, SKUs, quantities, prices, units, weights, dimensions, and packaging. Service sales and service purchases are excluded because they do not represent inventory freight movements. ## Products and facilities Owlery synchronizes products, including deprecated products referenced by historical orders. Product mapping can include SKU, description, unit, weight, and dimensions. Unsupported units safely default to `each` for review. Facilities can come from: * Cin7 Core locations * Child locations that inherit a parent address * Customer and supplier address books * The shipping address on an order Owlery can resolve a missing location ID by name and prefers a supplier's default shipping address for purchase pickups. ## Multi-location sales When splitting is enabled, Owlery reads pick lines from the latest fulfillment and groups quantities by location ID. One SKU can be divided across multiple pickup locations. Owlery creates one linked freight order per location. Unallocated quantities remain visible for review. Later syncs reconcile changed assignments, preserve stable child identities where possible, and retire obsolete splits. ## Synchronization and reliability * **Incremental synchronization** uses update timestamps for sales and purchases. * **Pagination** retrieves large lists in API-sized pages and processes details in smaller batches. * **Targeted retries** retry temporarily unavailable detail records without discarding the rest of the page. * **Independent workflows** allow one order family to continue if another API request fails. * **Exact-reference lookup** supports a specific `SO`, `PO`, or transfer outside the background cycle. * **Stable reconciliation** handles changing fulfillment locations and quantities across later syncs. # Writing Back to Cin7 Core Source: https://help.owlery.ai/shippers/cin7-core/writing-back How Owlery returns selected pickup and delivery dates to Cin7 Core. Cin7 Core write-back is optional. Owlery recommends which date updates match your workflow, tests them against representative records, and introduces them after inbound synchronization is validated. Your team confirms the intended business outcome. Owlery configures, tests, and monitors the write-back behavior. ## Available date updates | Owlery event | Cin7 Core update | | ----------------------- | ------------------------------- | | Sales load picked up | Sale `ShipBy` | | Purchase load delivered | Purchase `RequiredBy` | | Transfer load picked up | Stock transfer `DepartureDate` | | Transfer load delivered | Stock transfer `CompletionDate` | Owlery uses the actual stop date first and can fall back to the matching tracking-event date. ## Safe writes by design * Split Owlery orders sharing one Cin7 Core source are grouped so the source updates once. * Owlery retrieves the current record before writing and preserves unrelated fields. * Requests are paced for Cin7 Core API limits. * Rate-limit responses use bounded exponential backoff. * Validation and authentication failures are not blindly retried. * Missing source identities, dates, or unsupported order types produce actionable failures. Start with read-only synchronization, then enable one date workflow at a time after the corresponding inbound order type is validated. # Cin7 Omni Integration Scope Source: https://help.owlery.ai/shippers/cin7-omni Understand the current Cin7 Omni mapping foundation and how Owlery scopes a connection. Owlery has an inbound mapping foundation for Cin7 Omni sales and purchase orders. It translates freight-relevant order, contact, address, status, and line-item data into Owlery. Cin7 Omni and Cin7 Core (formerly DEAR Inventory) are separate products with different APIs. Cin7 Core has a broader production connector with date write-back; this guide covers the Cin7 Omni scope. Cin7 Omni is not a self-service connector — Owlery confirms technical availability and scope before enablement. ## Current integration foundation Review the implemented sales-order and purchase-order mappings, synchronization design, and rate controls. Understand which authentication, item-master, transfer, custom-field, and write-back capabilities require scoping. Write-back is not part of the current standard scope. Owlery documents any requested outbound workflow separately during solution design. ## Getting started Confirm your system is Cin7 Omni. Owlery reviews the supported authorization method and current connector availability for your account. Owlery determines the supported authorization method and verifies safe read access. After read access is available, Owlery reviews sample sales or purchases to understand statuses, addresses, contacts, items, and exceptions. Your team confirms the proposed mapping, scope, and any additional implementation work before rollout begins. To review Cin7 Omni availability, email [support@owlery.ai](mailto:support@owlery.ai). # Cin7 Omni Reading Scope Source: https://help.owlery.ai/shippers/cin7-omni/reading-data The implemented sales and purchase mapping foundation and its current boundaries. The current Cin7 Omni foundation maps inbound sales and purchase orders into Owlery. Production availability and authentication are confirmed during implementation. ## Implemented mappings | Cin7 Omni record | Current Owlery mapping | | ---------------- | ---------------------------------------------------------------------------- | | Sales Order | Customer shipment with delivery stop, contact, status, notes, and line items | | Purchase Order | Supplier shipment with pickup stop, contact, status, notes, and line items | Mapped data can include the Cin7 Omni order ID, created and modified timestamps, source status, delivery instructions, customer or supplier details, billing address, item name, line comments, expected and shipped quantity, unit price, and barcode. The mapping recognizes `Draft`, `Submitted`, `Confirmed`, `Cancelled`, and `Closed`. Other source values require review before rollout. ## Synchronization design The connector foundation is designed to: * Retrieve sales and purchase orders changed since the prior successful synchronization * Request paginated order lists * Pace requests against minute and daily API allowances * Resolve missing city, state, or country values from a postal code when possible * Preserve source IDs and modification timestamps ## Current boundaries The current standard scope does not include: * Completed self-service authentication and token handling * Item-master synchronization * Stock transfers * General custom-field mapping * Shipment, fulfillment, receipt, or status write-back Owlery identifies any additional work explicitly during solution design. The page describes implemented mapping foundations, not a generally available production connection. # Coming Soon Source: https://help.owlery.ai/shippers/coming-soon Analytics documentation is being added over time — here's what's covered so far. We're adding analytics documentation over time. Pages go up as each dashboard is finalized, so this section will keep growing. ## Documented So Far What every tile and chart on the Spot Loads dashboard means, and how spot savings is calculated. ## Still to Come Dashboards for spend, lane performance, carrier scorecards, and invoice trends are under active development. In the meantime, you can export data from most tables with **Download CSV** and analyze it in your own tools. Have a dashboard you'd like documented first? Email [support@owlery.ai](mailto:support@owlery.ai) and let us know. # Contact Settings Source: https://help.owlery.ai/shippers/contacts Set the fallback people Owlery emails about quoting, logistics, ASN issues, and payment statements. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Contacts` Contacts are your organization's "if in doubt, email this person" addresses. Owlery always prefers a more specific person when it knows one — the teammate who created the order, or the person who tendered the load. These contacts catch everything else, so notifications never quietly go nowhere. ## How Contacts Work Each contact has a name, an email address, and an optional phone number. * **Adding a contact**: most of these settings accept more than one contact. Click **Add Contact** to add another. * **Removing a contact**: removing a contact here only removes it from *this* role. The contact record stays in your address book and keeps any other roles it has. * **Falling back**: the Logistics Contact is the safety net for the other three settings. If one of them has no contact of its own, its notifications go to the Logistics Contact instead. Setting the Logistics Contact is the highest-value thing you can do in this group. Everything else falls back to it. ## Logistics Contact **What it does:** Your organization's general logistics contact. Owlery uses it for quoting and day-to-day logistics messages when there is no specific user contact for the shipment. **When you'd change it:** When the person or shared inbox responsible for shipping changes, or when you want a team alias such as `shipping@yourcompany.com` receiving these instead of one individual. ## Data Write Back Notification Contact **What it does:** Gets an email when Owlery tries to write information back into your ERP or business system and the write fails. **When you'd change it:** Point this at whoever owns the ERP connection — usually someone in IT or finance systems — rather than an operations inbox. Fixing these usually means fixing something on the ERP side. **If left empty:** These notifications go to the Logistics Contact. ## Retail ASN Issue Contact **What it does:** Gets an email when Owlery can't send an ASN (the advance shipping notice your retail customers require) because something required is missing — for example, a product is missing its GTIN-14 barcode number. **When you'd change it:** Point this at whoever can fix product and item data, since that is almost always the cause. **If left empty:** These notifications go to the Logistics Contact. Catch these quickly. A blocked ASN can turn into a retailer chargeback. ## Payment Statement Contact **What it does:** Sets who receives the payment statement emails Owlery generates — a CSV listing invoices approved for payment. This is normally accounts payable. **When you'd change it:** Add a person when someone new joins AP. Turn on GL routing when one combined statement stops being useful because several departments need to see only their own charges. ### Routing Statements by GL Code Turn on **Payment statement notifications by GL code** if different parts of your business pay for their own freight. Tag each contact with the GL codes they are responsible for, and Owlery sends each person only the statements matching their codes. A contact with no codes listed receives the default statement. When GL routing is on, each contact is listed with its codes after a dash — for example `AP Team — GL: 5010, 5020`. A contact with no codes shows as `— GL: Default`. Statements can also be generated automatically on a schedule. See **Approved Invoice Auto-Batching** in [Freight Audit and Pay Settings](/shippers/freight-audit-and-pay). # Overview Source: https://help.owlery.ai/shippers/contract-rates-overview Store the contract rates (or Rates on File) you have with your carriers. **Where to find it:** `Dashboard → Contracts` ## What are contract rates? Contract rates (also called Rates on File) are pre-negotiated rates you have with specific carriers for specific lanes. Once stored in Owlery, they can be used to automatically price loads, build loads in bulk, and streamline the quoting and tendering process. ### What a rate is made of * Each rate links a **shipper ↔ carrier/broker** pair. * It carries a **lane** (stops), **equipment type**, **mode** (FTL or LTL), **rate amount,** and an optional date range. * Rates can be FTL, LTL by pallet, or LTL by weight. ### Creating them * **CSV upload** for bulk: download the matching template (it changes by rate type) and review validation before committing. * **+ Add Rate** for a single lane. * [**Run an RFP**](/shippers/rfps/overview) to have your carriers bid on lanes — the bids you award land here as contract rates. * Attach a **Fuel Schedule** (percentage or per-mile) so surcharges are added automatically. ### Bulk-tendering with your rates * Use **Build Contract Loads** to create and tender many loads from one rate at once — pick a contract, set dates and counts, and submit. *(Requires the Build Contract Loads add-on.)* **If a rate won't match a lane**: make sure stop addresses match your saved Facility Profiles and that your shipment dates fall inside the contract's active date range. # Contract Rates Page Source: https://help.owlery.ai/shippers/contract-rates-page Navigate the Active, Expired, and Upcoming tabs and read the contracts table and detail drawer. ### The Three Tabs When you open the page, you'll see three tabs: | Tab | What's in it | | ------------ | --------------------------------------------------------------------------------------------------- | | **Active** | Rates currently in effect. These are available for quoting and tendering. | | **Expired** | Rates whose contract end date has passed. Kept for reference but won't be used for new quotes. | | **Upcoming** | Rates whose contract start date is in the future. They'll automatically become Active on that date. | ### Understanding the Contracts Table Each row represents one contract rate. | Column | What it shows | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Carrier** | The carrier/broker the rate is with. Shows name, DOT/MC numbers, and SCAC where available. | | **Stops** | A visual lane diagram showing stops (origin → destination), with transit times and distances between stops. | | **Rate** | The price for this contract (line-haul or total depending on configuration). | | **Equipment** | Dry Van or Reefer. | | **Team/Solo** | Whether the rate is for a solo driver or a team. | | **All In** | Shows "Fuel Schedule" if the rate has a linked fuel surcharge table, or "All In" if fuel is included in the base rate. | | **Transit Days** | Estimated transit time in business days. | | **Active Dates** | The contract's start and end dates. | | **Updated By / Updated At** | Who last modified the rate and when. | Click any row to open a detail drawer with two tabs: * **Details**: Full breakdown: carrier, every stop with appointment times, equipment, rates (FTL stop-count ranges or LTL pallet/weight tiers), extra stop charges, line items, and who last updated it. * **Fuel Schedule**: Appears only if the rate has a linked fuel surcharge table. Shows the full tiered fuel price → surcharge mapping. # Document Settings Source: https://help.owlery.ai/shippers/documents Choose which shipment documents your team can generate, including custom templates built for your workflow. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Documents` These settings control which shipment documents your team can generate — three standard documents that are always available, plus any custom templates built for your workflow. Turning a document on here makes it available in the document menus on loads, orders, and quotes. Turning a document on doesn't send it. When and to whom documents get sent is set under Tender Defaults in [Tendering Settings](/shippers/tendering). ## Standard Documents These three are always available and can't be turned off. | Document | What it's for | | ------------------------ | -------------------------------------------------------------------------------------------------- | | **Bill of Lading (BOL)** | The core shipping document — the carrier's instruction and receipt. It travels with the freight. | | **Packing List** | What's in the shipment: items, quantities, and packaging. Receiving uses it to check the delivery. | | **Shipping Label** | The label applied to the freight itself. | ## Advanced Document Package The Advanced Document Package lets you add custom document templates beyond the standard three — anything your workflow or your customers require. A template can be almost any document you need generated against a shipment: customs paperwork, a customer-specific packing slip, a compliance form, a branded BOL. If the package isn't active on your account, you'll see an unlock prompt here — request access from that prompt. ### How Templates Get Added Templates are built by Owlery and configured by you. 1. **Request the template.** Tell Owlery what document you need and send an example of the format — a blank copy of the form, or a filled-in one from a customer. 2. **Owlery builds it** and enables it on your account. 3. **Turn it on here.** Each template appears in this group as its own On/Off setting. Turning it on makes the document available in the document menus on loads, orders, and quotes. 4. **Fill in its fields.** Some templates carry their own settings — values that are the same on every copy, so you set them once here rather than per shipment. These appear below the template once it's turned on. Once a template is on, it also becomes available in Tender Defaults, where you choose whether and when it's sent. ### Example: Canada Customs Invoice The Canada Customs Invoice is a good illustration of how a template with its own fields works. It's the document Canadian customs requires to clear commercial goods entering Canada, and you'd turn it on if you ship into Canada — without it, your freight can be held at the border. Turning it on reveals four fields. They print on every copy of the document, and the field numbers match the numbered boxes on the official customs form, so they line up with a paper copy or your broker's instructions. | Setting | Field | What to enter | | ---------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **Vendor** | 1 | Name and address of the vendor selling the goods — usually your own company. | | **Exporter** | 19 | Name and address of whoever is shipping the goods out of the country. Often the same as the vendor, unless a third party handles your exports. | | **Country of Transshipment** | 6 | The country the goods pass through under customs control on the way to Canada. Leave blank for direct shipments. | | **Consignee Account Number** | Added to 4 | An account number your Canadian customer or their broker has asked to appear on customs paperwork. | Incomplete or incorrect customs paperwork is a common cause of freight sitting at the border. If you're unsure what belongs in these fields, your customs broker will know — and it's a one-time setup. Other templates have their own fields, or none at all, depending on what the document needs. # Exception Settings Source: https://help.owlery.ai/shippers/exceptions Control which carriers' exceptions appear in your Needs Attention queue. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Exceptions` An exception is Owlery flagging that a shipment needs someone to look at it — a missing document, a tracking update that never arrived, or a date that has slipped. Exceptions collect in your **Needs Attention** queue, which is the list your team works through. The queue is only useful if everything in it is worth acting on. These settings are how you keep it that way. ## Excluded Carriers from Exceptions **What it does:** Loads assigned to the carriers you list here stay out of the Needs Attention queue. Carriers are listed by their integration name, so you're picking recognizable names rather than codes. **When you'd use it:** When an integrated carrier reliably raises exceptions that aren't real problems. A common case is a carrier whose system doesn't send the tracking updates Owlery expects, so every load with them looks like it's missing information. Excluding them stops that noise burying the exceptions your team actually needs to act on. **When you wouldn't:** Don't use it to quiet a carrier with genuine service problems. Those exceptions are exactly the ones you want in front of your team. This hides, it doesn't disable. Exceptions are still raised, stay open, and remain visible on the load itself — they're just not queued for action. # Freight Audit and Pay Settings Source: https://help.owlery.ai/shippers/freight-audit-and-pay Automate invoice approvals and disputes, batch approved invoices into payment statements, and set carrier payment terms. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Freight Audit and Pay` Freight invoices routinely don't match what was quoted. These settings automate the checking that's mechanical, so your team's attention goes to the invoices that actually need it. If Freight Audit and Pay isn't active on your account, these settings are visible but read-only, with an unlock prompt at the top — request access from there. One term to know: the **awarded rate** is the price you agreed when you booked. Most of what follows compares the invoice against it. ## Invoice Auto Decision **Value:** On / Off **What it does:** The master switch. When on, invoices that meet your rules are approved or disputed automatically instead of waiting for someone to review them. **When you'd turn it on:** Once you've set up your rules and you're comfortable with what they'll do. Define the rules first, then enable. ## Invoice Auto Decision Rules **What it does:** Defines the actual rules. There are two, and they're independent — use either or both. * **Approve rule**: when *all* of its conditions are met, the invoice is approved automatically. * **Dispute rule**: when *any one* of its conditions is met, the invoice is sent back as disputed. That difference is deliberate. Approving needs everything to check out; a single problem is enough to justify a dispute. If neither rule applies, the invoice stays in **Needs Review**. If both match, the dispute wins. To create a manual-review range, set a low approve threshold and a higher dispute threshold. Invoices that land between the two stay in **Needs Review** for a person to look at. ### What Each Rule Can Check Every rule has an on/off switch and can combine a threshold with three conditions. **Threshold** is a dollar amount, plus a **Compare mode** for how it's measured: * **Overage**: looks only at how much the invoice is *above* the awarded rate. * **Absolute difference**: looks at the gap in either direction, so an invoice that's unexpectedly *under* the awarded rate also gets caught. On the approve rule the threshold means "at or below this amount" — or "exactly", if you set it to zero. On the dispute rule it means "above this amount". The three conditions read differently depending on which rule they're on: | Condition | On the approve rule | On the dispute rule | | --------------- | ---------------------------------------------- | --------------------------------------------------------- | | **POD** | Require POD on the load | Dispute when POD is missing from the load | | **ERP rate** | Require the awarded rate to match the ERP rate | Dispute when the awarded rate does not match the ERP rate | | **Order match** | Require every invoiced load to match an order | Dispute when any invoiced load does not match an order | POD is proof of delivery — the signed confirmation the freight arrived. Turning on a rule without a threshold or condition doesn't automate anything. Configure at least one check for each rule you enable. ### The Live Preview As you configure a rule, Owlery describes in plain English exactly when it will fire — for example *"Invoices will be auto approved when all of the following are true: the invoice overage is at or below \$50.00; POD is on the load."* Read this before saving. It's the clearest check that the rule does what you meant. ### Carrier Overrides Pick a carrier integration and you can override the **approve rule**, the **dispute rule**, or both, just for that carrier. Anything you don't override falls back to your default rules. **When you'd use it:** Tighter rules for a carrier whose invoices are frequently wrong; looser ones for a long-standing partner whose invoices are reliably accurate. Start conservative — a small threshold, POD required — and loosen once you've seen it work. An auto-approve rule that's too generous pays overcharges silently, which is the one failure mode you won't notice. See [Invoices](/shippers/invoices) to review statuses and decision reasons after your rules run. ## Approved Invoice Auto-Batching **What it does:** Automatically gathers your approved invoices into payment statements on a weekly schedule, instead of someone assembling them by hand. | Setting | What it does | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Enable auto-batching** | The on/off switch. | | **Run day** and **Run time** | When it runs each week. Times are in your own time zone, which the page shows you. | | **Invoice filter** | Either **All approved invoices**, or **Approved invoices due within** a number of days you specify. The second option is how you pay only what's actually coming due. | | **Split payment statements by GL Code** | When on, each GL code gets its own statement; when off, everything eligible goes on one. | As you configure it, a line underneath describes in plain English what the run will do. **When you'd use it:** If you have a regular payment cycle, set the run to land just before it. Turn on GL splitting if different departments approve their own freight spend. Who receives these statements is set by **Payment Statement Contact** in [Contact Settings](/shippers/contacts). Set that first, or the statements have nowhere to go. ## Disputed Invoice Digest **Value:** On / Off **What it does:** Sends a once-a-day summary email, to your carrier account manager and accounting contacts, of the invoices that were sent back as disputed. **When you'd turn it on:** So disputes get chased rather than sitting. A daily digest is usually the right rhythm — frequent enough that nothing ages badly, infrequent enough that people read it. ## Carrier Payment Terms **What it does:** Works out when each invoice is actually due, so you can review, filter, and export by due date. You set a **default rule** and, optionally, **per-carrier overrides**. A rule has two parts: * **Net days**: how many days you have to pay. * **Base date**: what those days count from — the **Invoice Date** (the date on the carrier's invoice) or **Invoice Received** (the date it reached Owlery). They display as, for example, `Net 30 from Invoice Date`. The current values are shown with the default first, then each carrier override. **Why the base date matters:** An invoice dated the 1st that reaches you on the 15th is due at very different times under the two options. Match whichever your carrier contract specifies. **When you'd set overrides:** Payment terms are negotiated per carrier, so they often differ. Set the term you use most as the default, then override the exceptions. Saving your terms recalculates the due date on existing invoices — you don't need to update anything manually. If a carrier has no override and you've set no default, their invoices have no due date. If the carrier's own stated due date differs from the one Owlery calculates, the invoice detail drawer flags it. Neither date overwrites the other, so you can spot the discrepancy. # Fuel Surcharges Source: https://help.owlery.ai/shippers/fuel-surcharges Create fuel surcharge schedules and pair them with contract rates so surcharges apply automatically. **Where to find it:** `Dashboard → Fuel Charges` The **Fuel Charges** page is where you manage fuel surcharge schedules. These can be linked to contract rates so surcharges are automatically applied based on the current fuel price. ### The Fuel Charges Table | Column | What it shows | | -------------- | -------------------------------------------------- | | **Name** | A note or label for the schedule. | | **Type** | **Percentage** or **Per-Mile**. | | **Currency** | USD, CAD, or MXN. | | **Rate Tiers** | How many price → surcharge tiers the schedule has. | Click a row to open a detail drawer showing the full tier table: * **Fuel Price Range**: The fuel price band (e.g., \$2.000 – \$2.499). * **Fuel Surcharge Rate** (percentage) or **Rate Per Mile** (per-mile): The surcharge that applies when fuel is in that range. ### Creating a Fuel Schedule Fuel schedules are created by CSV upload: Click the **Upload CSV** button, then pick your template from the dropdown: * **Download Percentage Template**: Columns: `Fuel Price From`, `Fuel Price To`, `Surcharge Rate` * **Download Per-Mile Template**: Columns: `Fuel Price From`, `Fuel Price To`, `Rate Per Mile` The **last tier** should have an empty `Fuel Price To` to mean "and above." Fuel prices use 3 decimal places (mills precision). Click **Upload CSV** again and select your file. The system validates and shows a preview. Confirm to create. ### Pairing a Fuel Schedule with a Contract Rate Once paired, the schedule appears in the contract rate's detail drawer → *Fuel Schedule* tab, and the *All In* column on the main table changes from "All In" to "Fuel Schedule."\ \ Once paired, the schedule appears in the contract rate's detail drawer → *Fuel Schedule* tab, and the *All In* column on the main table changes from "All In" to "Fuel Schedule."\\ Create a new rate or edit an existing one. In the **Fuel Charge Table** dropdown, select the schedule you want. The dropdown shows each schedule as `name - type - N tiers`. Once paired, the schedule appears in the contract rate's detail drawer → **Fuel Schedule** tab, and the **All In** column on the main table changes from "All In" to "Fuel Schedule." ### Tips * No fuel schedule = "All In" rate (fuel included in base price). * If using a per-mile schedule, fill in the **Total Distance** field on the contract rate so the system can calculate the surcharge. * The same fuel schedule can be reused across multiple contract rates. * Use **Download Template** on the contracts page to export all your existing rates with their linked fuel schedules for bulk review. # Getting Started in 4 Steps Source: https://help.owlery.ai/shippers/getting-started-in-4-steps Everything you need to set up, ship, and manage freight with Owlery. Setting up a new Owlery account? Do these in order — each one makes the next steps faster and reduces manual entry later. Link your ERP, brokers, and direct carriers so orders, rates, and tracking flow in automatically. (`Settings → Integrations`) [How to connect integrations →](/shippers/integrations-overview) Add your SKUs with packaging dimensions and weights — this drives pallet counts, BOL lines, and load building. (`Dashboard → Item Master`) [How to build your Item Master →](/shippers/item-master) Start with your Logistics Contact, then set quoting defaults (pallet size, weight, freight class). (`Dashboard → Shipper Settings`) [How to configure shipper settings →](/shippers/shipper-settings) Upload pre-negotiated lane prices so they surface automatically when you quote a matching lane. (`Dashboard → Contracts`) [How to add contract rates →](/shippers/adding-contract-rates) **Your day-to-day flow:** [Orders](/shippers/orders) → [Quotes](/shippers/quotes) → [Loads](/shippers/loads) → [Invoices](/shippers/invoices) # Hootie, Your AI Logistics Teammate Source: https://help.owlery.ai/shippers/hootie Ask a question, get an answer in seconds — in Slack, Teams, or email, grounded in your live Owlery data. Hootie is Owlery's AI teammate. It runs on your live Owlery data and works where your team already does — Slack, Teams, or email — so anyone can get a shipment answer without opening Owlery or interrupting logistics. **Hootie is currently in beta.** It's available to Owlery customers on request — email [support@owlery.ai](mailto:support@owlery.ai) and we'll get you set up. Once you're in the beta, Hootie is added once for your whole workspace and works in channels or DMs: Added once for your whole workspace. Use in channels or DMs. Added once for your whole workspace. Use in channels or DMs. Message [hootie@owlery.ai](mailto:hootie@owlery.ai). Best for 1:1 threads. ### The difference it makes Without Hootie, a simple question takes a detour through your logistics team: 1. Someone asks "where's the Walmart PO?" 2. Logistics sees it two hours later. 3. They open Owlery and search for the load. 4. They screenshot the status and paste it back. With Hootie, anyone asks `@hootie` — in a channel, a DM, or over email — and gets an answer in seconds, grounded in your live Owlery data. **No context-switching. No waiting. No screenshots.** ### What Hootie does Anyone in the company can ask Hootie a shipment question from Slack, Teams, or email — no extra logins, no interrupting logistics. Hootie can tender loads, request quotes, and reach out to carriers. It confirms before doing anything — you stay in control. Set up standing instructions and Hootie monitors shipments, flags exceptions, and sends summaries on your schedule. ### Not just for the logistics team Hootie gives everyone logistics answers without pulling your team into every thread. | Team | What they use it for | | :----------------------------- | :---------------------------------------------------- | | **Sales & Account Management** | Answer "where's my order?" before the customer asks. | | **Customer Service** | Self-serve shipment lookups during live calls. | | **Operations & Warehouse** | See what's shipping today and what's coming in. | | **Leadership** | On-demand updates without pinging the logistics team. | ### Try asking Hootie **Quick lookups** * `@hootie get me the POD for WalMart PO 867-5309` * `@hootie what's the latest with D296PE165? did it deliver?` * `@hootie where's the shipment for PO #4521?` * `@hootie how many pallets is SO_919718 going to ship as?` **Information on demand** * `@hootie what orders do I have shipping today?` * `@hootie what Twinstar orders delivered this week?` * `@hootie for all LTL loads shipping today, how many cases are on each one?` * `@hootie summarize all sales orders shipping today with ETA delivery, grouped by origin` **Load execution** * `@hootie PO-1234 is ready to ship` * `@hootie Can you tender all open orders to their contracted carriers?` * `@hootie Please get spot quotes for the following orders: SO-1234, SO-4567, SO-8910` **Autonomous monitoring** * `@hootie Each morning, check for any shipments that are late and send me a summary in Slack` * `@hootie keep an eye on 0176511 — it should ship tomorrow. confirm when it does, and again when it delivers` * `@hootie Reach out to the carrier on 8372654 and ask for an update on the ETA` You don't need to phrase things precisely. Hootie handles PO numbers, SO numbers, load numbers, and plain descriptions of what you're after. ### How your data is handled Hootie is powered by commercial LLMs that we have optimized for logistics. Your data is never used to train the model, and Hootie always confirms before taking action. ### Get access Hootie is in beta and we're onboarding customers one at a time so we can tune it to how your team works. To request access, email [support@owlery.ai](mailto:support@owlery.ai) and let us know whether you'd want it in Slack, Teams, or email, and which teams would use it. We'll handle the setup with you — there's nothing to install on your side first. # Overview Source: https://help.owlery.ai/shippers/integrations-overview Connect Owlery to the systems and partners you rely on to keep your supply chain moving. **Where to find it:** `Settings → Integrations` Connect Owlery to the systems you already run so data moves on its own. **Owlery connects to far more systems than we document here.** This section has detailed guides for some of our most-used connectors (the ones listed in the sidebar). The categories below show the full range we support and for anything without a guide, our team will walk you through the setup. Not sure whether we support yours? Email [support@owlery.ai](mailto:support@owlery.ai). ### Types of systems Owlery can connect to * **ERP / Order systems / IMS:** NetSuite, SAP, Business Central, Cin7, Katana, and more. Pulls orders in; supported connectors can also write selected shipment or accounting events back. * **Carriers & Brokers:** CH Robinson, Echo, TQL, RXO, and many others. Get rates, create BOLs, tender loads, track, and receive invoices and documents. * **WMS & 3PLs:** Extensiv, your 3PL warehouse partner, and dozens of WMS. * **Visibility & IoT devices:** Tive, Motive, Sensitech, and more. * **Accounting / AP systems:** QuickBooks Online, Ramp, and others. * And more via our [Open API](https://owlery.ai/open/api) Looking for an AI assistant connector? See [AI Assistants & MCP](/shippers/ai-assistants-and-mcp). ### How to add an integration Click **+ Add Integration** and pick your system. These vary by vendor — API key, OAuth login, or username/password. Click **Test & Save**. Owlery validates the connection before saving, then syncing begins on the next poll. ### Keeping connections healthy * Check sync status right on the Integrations page — **green** means the last sync worked, **yellow/red** means there’s an issue. * Admins can trigger a manual **Re-Sync** from the integration panel any time. * You can run **multiple integrations of the same type** (e.g. two NetSuite instances for different subsidiaries). If you change a password or rotate an API key with a vendor, update it in Owlery right away to avoid sync interruptions. # Invoices Source: https://help.owlery.ai/shippers/invoices Review what carriers bill against what you agreed to pay, then approve or dispute. **Where to find it:** `Dashboard → Finance → Invoices` Review what carriers bill against what you agreed to pay, then approve or dispute. The Invoices page in the Owlery dashboard ## The review workflow Tabs follow the payment stages. Start your day on **Needs Review**, sorted by payment due date. | Tab | What it means | | ------------------- | ------------------------------------------------------------------------------------------- | | **Needs Review** | Submitted by the carrier and waiting on your decision. Carriers see this as *Under Review*. | | **Approved** | You've approved the invoice for payment, but payment hasn't been initiated yet. | | **Disputing** | You've disputed the invoice. Carriers see this as *Disputed*. | | **Payment Created** | A payment has been initiated but hasn't fully cleared. | | **Paid** | Payment has cleared. | | **Archived** | Invoices you've hidden from the active views. Shipper-only tab. | The number badge on each tab shows how many invoices are currently in that state. ## Reading the comparison * **Awarded** is what you agreed to pay; **Actual** is what the carrier billed. * **Difference** is color-coded — **green** if billed under, **red** if over. * Line items show exactly where charges diverged. * **Loads** shows which loads the invoice covers. One load can appear on multiple invoices, and one invoice can cover multiple loads. ## Approve or dispute * **Approve** with an optional label and reason for your records. * **Dispute** with a label and reason — the carrier gets a daily digest of what was sent back, and both the label and reason are visible to them in their invoice view. * Select multiple rows to approve in bulk. ## What carriers see when you dispute When you dispute an invoice, the label and reason you enter are shared directly with the carrier in three places: * The **Dispute Label** and **Dispute Reason** columns in their invoice table. * A red *"Why this invoice is disputed"* alert at the top of the invoice detail drawer. * The **History** tab of the invoice drawer, which shows the full status-change timeline. Carriers can't see internal fields like tags, GL codes, auto-batch status, accounting sync records, or who on your team took each action. ## Who receives invoice emails Automated invoice emails go only to contacts configured for that workflow. Adding someone as an Owlery user does not automatically subscribe them to invoice emails. | Event | Recipient | What they receive | | ------------------------------ | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | An invoice is disputed | The carrier's **Account Manager** and **Accounting** contacts | If **Disputed Invoice Digest** is on, a daily digest lists the invoice number, linked load numbers, amount, disputed date, and a link to the invoice. The dispute label and reason are available in the linked invoice view. | | A payment statement is created | Your **Payment Statement** contacts | An email with the statement ID, links to **Payment Statements** and **Payment Created** invoices, and the complete statement CSV. The CSV includes invoice and line-item details using your organization's export format. | | The carrier's payment clears | The carrier's **Accounting** contacts | A remittance email with the shipper, carrier, amount paid, payment date, statement ID, and a link to the paid invoices. The attached carrier-safe CSV lists the statement ID, invoice number, amount paid, and payment date. | ### Set up carrier contacts 1. Go to [`Dashboard → Master Data → Contacts`](https://owlery.ai/dashboard/contacts). 2. Click **Add Contact**, enter the carrier contact's email, and confirm the carrier relationship shown. 3. Choose **Account Manager** for dispute digests, **Accounting** for dispute digests and payment remittances, or add both roles from the contact's **Roles** cell after creating the contact. 4. To send dispute digests, go to `Dashboard → Shipper Settings → Freight Audit and Pay`, open **Disputed Invoice Digest**, and turn it on. Payment remittances do not have a separate email toggle. Owlery sends them to the carrier's **Accounting** contacts after the carrier payment clears. ### Set up payment statement contacts 1. Go to [`Dashboard → Shipper Settings → Contacts`](https://owlery.ai/dashboard/shipper-settings?section=contacts). 2. Open **Payment Statement Contact**, click **Manage**, and add each recipient. 3. Leave **Payment statement notifications by GL code** off for every contact to receive every statement. To route statements by GL code, turn it on, assign GL codes to each contact, and click **Save**. A contact with no GL code is the fallback for statements with no matching route. ### Split payment statements by GL code When you select invoices and click **Pay Now**, turn on **Separate statements by GL code** to create a separate payment statement and CSV for each complete GL-code set. For example, invoices assigned to one code, a different code, both codes, and no GL code become four separate statements. **Separate statements by GL code** controls which invoices belong to each statement and CSV. **Payment statement notifications by GL code** only routes each already-created statement to the matching contacts. Each recipient receives the complete CSV for that GL-split statement. In the current invoice review and payment workflow, **Logistics Contact** does not receive these emails. Owlery also does not send a contact-role email when an invoice first enters **Needs Review** or moves to **Approved**; use those tabs to monitor those stages. ## Automating decisions **Invoice Auto Decision Rules** can approve, dispute, or hold invoices based on the awarded rate, POD, ERP rate, and order link. You can set defaults for all carriers and replace either rule for a specific carrier. See [Invoice Auto Decision Rules](/shippers/freight-audit-and-pay#invoice-auto-decision-rules) to configure thresholds, checks, and carrier overrides. ## When a carrier resubmits an invoice Carriers can correct and resubmit an invoice as long as it's still in **Needs Review** or **Disputing**. Once an invoice moves to **Approved**, **Payment Created**, or **Paid**, it's locked — the carrier can't overwrite it, and they'll need to contact you to move it back before they can resubmit. Resubmissions arrive through the same channel the carrier used originally — EDI 210, the external API, CSV upload, or an edit to a manually created invoice in Owlery — and are matched to the existing invoice by invoice number. When a resubmission comes in on an unlocked invoice: 1. **The existing invoice is replaced in place.** Line items, totals, load numbers, invoice date, party info, and reference numbers are all updated. The invoice number and payment status stay the same, so a disputed invoice remains on the **Disputing** tab. 2. **Auto-Decision Rules re-run immediately** against the updated data. If the correction fixes the issue (e.g., the total now falls within your threshold, or a missing POD is now on file), the invoice can auto-approve or land back in **Needs Review** within seconds. 3. **Exceptions refresh.** Price variance, missing POD, and ERP mismatch flags are recomputed. 4. **You're notified.** Webhooks fire and the invoice reappears in your workflow with its new values. Auto-Decision Rules only re-evaluate invoices that were **auto-disputed**. If someone on your team manually disputed an invoice, a carrier resubmission updates the invoice data but leaves it in **Disputing** for you to review — the system won't override a human decision. ## Finding paid vs. disputed invoices * **Paid invoices:** Open the **Paid** tab. Payment Created shows invoices where payment is in flight but not yet cleared. * **Disputed invoices:** Open the **Disputing** tab. Click any row to see the dispute label, reason, and full history in the drawer. # Item Master Source: https://help.owlery.ai/shippers/item-master Your product catalogue — Owlery reads it every time a load or order is created. **Where to find it:** `Dashboard → Item Master` Your product catalogue. Owlery reads it every time a load or order is created. ## Three ways to add items * **Manually**: **+ Add Item**, one SKU at a time. * **CSV upload**: download the template, one row per SKU, re-upload. Owlery validates before saving. * **Integration sync**: items flow in from a connected WMS or ERP. ## The fields that drive everything * **SKU**: required and unique. * **Packaging hierarchy**: dimensions and weight per level (each → case → pallet) powers automatic pallet counts. * **Handling, reefer & hazmat** toggles tell Owlery how the item must ship. ## Editing & cleanup * **Bulk Edit** mode uses Keep / Yes / No / Clear per field — “Keep” leaves existing values alone. * **Archive** instead of deleting to keep history; restore any time. * **Re-SKU** and **Variant** uploads rename or map codes while preserving history. ## How do SKU temperatures affect quoting? From the SKUs on the quote. If every SKU that has a temperature shares the same settings, those settings pre-fill the quote and the equipment type switches to **Reefer** automatically. Owlery leaves the temperature fields blank and keeps the equipment on **Dryvan** — you'll set the temperature yourself. No. They're ignored and won't block the other SKUs from pre-filling. The item's settings in your item catalog. Edit the item there and future quotes will use the new value. ## When something looks off Check the **packaging hierarchy** first — pallet counts are calculated from the dimensions and weight at each packaging level (each → case → pallet). This means a SKU has no packaging info — add dimensions and weight to the item. **Don't accidentally erase data**: on CSV upload, the **Clear empty fields** toggle erases data for any blank column when on. Leave it off unless you mean to wipe values. # Katana Integration Source: https://help.owlery.ai/shippers/katana Sync Katana orders, inventory, and products into Owlery, with supported carrier fulfillment tracking. Owlery connects to Katana through its API. We synchronize orders, locations, products, materials, and inventory into Owlery, then configure supported fulfillment tracking when it fits your carrier workflow. After your Katana administrator authorizes the connection, Owlery discovers the account and recommends the mapping. Your team confirms the result; Owlery handles configuration, validation, and rollout. **Where to find it:** `Settings → Integrations` ## Three parts of the integration Synchronize sales, purchase, and transfer orders plus locations, variants, and inventory. Review the currently supported carrier-specific fulfillment-tracking workflow. Review order scope, history, status, facility, item, and tracking controls. ## Getting started A Katana administrator [connects Katana to Owlery](/shippers/katana/connect). The administrator signs in to Katana and approves access; Owlery handles the OAuth 2.0 credentials and tokens. Share representative sales orders, purchase orders, or stock transfers. Owlery learns your locations, variants, units, statuses, and fulfillment behavior from the data. Owlery presents the recommended order scope, mappings, and applicable tracking workflow. Your team confirms the order, facility, item, and tracking behavior match the intended outcome. Owlery validates normal, exception, and tracking scenarios, starts synchronization, and monitors the first records. Need help planning your Katana connection? Email [support@owlery.ai](mailto:support@owlery.ai). # Katana Configuration Reference Source: https://help.owlery.ai/shippers/katana/configuration Order scope, synchronization, mapping, and supported tracking controls. Owlery reviews your Katana account and recommends the relevant controls. Your team confirms the result; Owlery maintains the configuration. | Area | Available controls | | ----------------------- | ------------------------------------------------------------------------------ | | Overall synchronization | Enable or disable Katana background synchronization | | Order scope | Enable or disable sales, purchase, and transfer orders independently | | Initial history | Run a full synchronization when historical records are needed | | Ongoing changes | Retrieve records changed since the prior successful sync with boundary overlap | | Exact lookup | Find an order by its Katana order or transfer number | | Status interpretation | Map transaction statuses to Owlery order states | | Facility mapping | Build origins and destinations from Katana locations and shipping addresses | | Item identity | Preserve variant IDs while interpreting SKU, name, and unit data | | Tracking write-back | Enable the currently supported carrier-specific fulfillment workflow | ## Authentication details Katana uses OAuth 2.0. Owlery stores account-specific access and refresh tokens and can refresh expired access. A connection-level lock prevents concurrent workers from rotating the same refresh token. Read access can include orders, fulfillments, locations, customers, suppliers, variants, products, materials, and inventory. Write access to sales-order fulfillments is needed only when supported tracking write-back is enabled. # Connect Katana to Owlery Source: https://help.owlery.ai/shippers/katana/connect Authorize Katana in a few clicks while Owlery handles the OAuth 2.0 credentials and token refresh. Connecting Katana is a one-time approval. You do not need to create an app, copy API keys, or understand OAuth 2.0. **Where to find it:** `Settings → Integrations` OAuth 2.0 is a secure approval flow between Katana and Owlery. You sign in to Katana and approve access. Katana then gives Owlery a revocable token instead of sharing your password. ## Before You Start You need: * A Katana account with permission to authorize integrations * Your Owlery sign-in * Access to the Katana account you want to connect If you belong to more than one Katana account, confirm that you are signed in to the correct account before you approve access. ## Connect Katana In Owlery, go to `Settings → Integrations`. Find **Katana** and click **Connect**. Owlery sends you to Katana's secure sign-in page. Sign in with a Katana account that can authorize integrations. If your browser blocks the new page, allow pop-ups for Owlery and click **Connect** again. Review the access request and approve it. This lets Owlery synchronize the Katana records described in [Reading Data from Katana](/shippers/katana/reading-data). You do not need to copy the authorization code shown in Katana's technical documentation. Katana sends it directly to Owlery. Katana sends you back to Owlery. Confirm that the Katana integration shows **Connected**. ## What Owlery Handles Owlery maintains the registered Katana application, exchanges the one-time approval for secure tokens, stores those tokens, and refreshes access automatically. Your team does not need to create or rotate credentials. Katana publishes the underlying flow in [Setting up OAuth 2.0](https://developer.katanamrp.com/page/setting-up-oauth). That page is written for developers; the steps above are all you need for the Owlery connection. ## Troubleshooting Ask a Katana administrator or account owner to complete the connection. Then return to `Settings → Integrations` and try again. Go back to `Settings → Integrations` and click **Connect** again. Complete the approval in one browser session. If it still fails, send the error message to [support@owlery.ai](mailto:support@owlery.ai). Disconnect Katana in Owlery. Sign out of the incorrect Katana account, sign in to the intended account, and repeat the connection steps. See which Katana records Owlery synchronizes after authorization. # Reading Data from Katana Source: https://help.owlery.ai/shippers/katana/reading-data How Owlery synchronizes Katana orders, locations, variants, and inventory. Once Katana is authorized, Owlery retrieves changed transactions and the linked master data needed to build complete freight orders. ## Synchronized records | Katana record | How Owlery uses it | | -------------- | ---------------------------------------------------------------- | | Sales Order | Customer shipment from a Katana location to the shipping address | | Purchase Order | Supplier shipment arriving at a Katana location | | Stock Transfer | Internal inventory movement between Katana locations | | Location | Facility with a stable Katana source ID | | Variant | Item-master record for a product or material | | Inventory | Location-specific stock quantities for a variant | Order mapping can include IDs, order numbers, statuses, timestamps, customers or suppliers, facilities, dates, references, notes, variants, quantities, units, prices, and totals. ## Account-specific interpretation * Sales destinations use the order shipping address; origins use Katana locations. * Country and state values are normalized when possible. * E-commerce context can identify a sales order as parcel. * Product and material units can map to quantity, weight, length, or volume units. * Katana permits duplicate SKUs, so Owlery preserves the variant ID as the stable item identity. * Inventory can include in-stock, committed, reorder-point, and missing-or-excess quantities by location. Current inventory synchronization does not import Katana batch stock, lot codes, or expiration dates. ## Synchronization and reliability * **Rate pacing** keeps requests within the configured Katana allowance. * **Pagination** retrieves up to 250 records per page with a page safety limit. * **Incremental windows** use update timestamps and overlap the prior successful sync. * **Reference caching** avoids repeatedly fetching the same customer, supplier, facility, or variant. * **Stable identities** use Katana record IDs for orders, facilities, and variants. * **Targeted refresh** reloads one order directly from its source record. * **Exact lookup** finds an order by Katana order or transfer number. # Writing Back to Katana Source: https://help.owlery.ai/shippers/katana/writing-back The supported carrier-specific sales-order fulfillment tracking workflow. Katana write-back currently supports fulfillment tracking for a specific carrier workflow. Owlery confirms whether this workflow applies before enabling it. This is not a general fulfillment or receipt write-back feature for every carrier. Owlery documents any additional outbound workflow separately. ## Supported behavior When the supported tender workflow returns a tracking number, Owlery can: * Read the current Katana sales-order rows and quantities * Create a `PACKED` fulfillment when none exists * Add the carrier tracking number, tracking URL, and carrier name * Update only the tracking fields on one existing fulfillment * Treat already-matching tracking data as a successful no-op * Record a separate success or failure for every Katana order in a consolidated shipment ## Safe writes by design Owlery does not overwrite a different tracking number or guess when Katana returns multiple fulfillments. If a create request fails after Katana may have accepted it, Owlery queries the fulfillment again before returning an error. This recovery check reduces duplicate records after a timeout. * Fulfillment creates include the source sales-order rows and quantities. * Existing records receive tracking-only updates. * Per-order audits preserve actionable results. * Matching tracking values do not generate unnecessary updates. Validate inbound Katana sales orders first. Enable tracking only after Owlery confirms that the supported carrier workflow and fulfillment structure match your account. # Load Settings Source: https://help.owlery.ai/shippers/load-settings Set your on-time grace periods, control when loads can be created, and use one shipment ID throughout. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Load` A load is the shipment once it's real — a carrier is booked and the freight is moving. These settings control how you measure carrier performance, how loads get created, and how shipments are identified. ## On Time Performance **What it does:** Sets how late a pickup or delivery can be and still count as on time. Two values, both in minutes: * **Pick up grace period**: applies to pickups. * **Drop off grace period**: applies to deliveries. These feed the on-time performance figures on your dashboards. **When you'd change it:** Match them to what you and your carriers consider acceptable. A 0-minute grace period marks almost every carrier late, which makes the metric useless for spotting who is genuinely underperforming. 15–60 minutes is common, and it's reasonable to be more forgiving on pickups than deliveries — your customer is waiting at the delivery end. This changes how performance is displayed. It does not change the recorded pickup and delivery times themselves. ## Load Without Carrier **Value:** On / Off **What it does:** Lets your team create a load before a carrier or broker has been chosen. **When you'd turn it on:** If you need the load in Owlery before booking is settled — the freight is committed and your warehouse needs to prepare, while carrier selection is still in progress. **When to leave it off:** If you'd rather loads only exist once they're properly booked, so none sit in limbo with no carrier attached. This setting only appears if manual load creation is enabled for your account. ## Universal Shipment ID **Value:** On / Off **What it does:** Uses one identifier — the quote's short ID — as the shipment's ID everywhere: on the tender, on the load, in emails, and in messages to connected systems. **When you'd turn it on:** So everyone uses the same number for a shipment. Without it, the same shipment can be referred to by different identifiers at different stages, which makes tracing a problem across quote, tender, load, and invoice harder than it needs to be — for you, your carriers, and anyone reading an email thread later. # Loads Source: https://help.owlery.ai/shippers/loads The actual shipment — created, tracked, and documented in one place. **Where to find it:** `Loads` The actual shipment — created, tracked, and documented in one place. ## Creating a load * **From an order** (recommended): route, items, stops, and brokers pre-populate. * Or check **Build Load without Order** to fill everything in manually. * You’ll need a **Load Number**, a **Price** over \$0, and a **Mode** (FTL / LTL / PTL). ## Finding loads fast * Tabs filter by status: **All, Needs Attention, Open, Delivered, Tendered,** plus Monitor and Fleet views. * **Needs Attention** surfaces loads with unresolved exceptions. * Export the current view with **Download CSV** (up to 10,000 rows). ## Inside the Load Drawer * **Tracking** shows the live timeline and map; share a link with outside stakeholders. * **Documents** lets you generate a BOL and store PODs and rate confirmations. * Update status, edit details, or **Cancel** and later **Restore** a load as needed. ## Archiving a load * Click the **three dots** on the right side of the table row for the load you want to archive. * Select **Archive** from the menu to remove the load from your active views. # Need Help? Source: https://help.owlery.ai/shippers/need-help How to reach Owlery support when setup or syncing isn't going to plan. If an integration isn’t syncing or setup isn’t going to plan, reach out with your organization name and which integration or section you’re configuring. > **Email Owlery support:** [**support@owlery.ai**](mailto:support@owlery.ai) If a teammate signed in but can't see your organization's data, that's usually an email domain issue rather than a support ticket — see [Invite Team Members](/inviting-team-members) first. # Configuration Reference Source: https://help.owlery.ai/shippers/netsuite/configuration The full set of configuration options Owlery supports for NetSuite — order scope, field mapping, routing, filtering, and more. This page documents every configuration option available for the NetSuite integration. You don't need to read this to get started — Owlery reviews your account and recommends the right settings. This reference exists for teams that want to understand the full range of what's possible. **You don't configure these yourself.** Owlery sets up and maintains all configuration. This page is a reference so you can see what's available and have informed conversations with our team. ## Configuration options | Area | Available controls | | ------------------------- | ----------------------------------------------------------------------------------------------------------- | | Order scope | Enable or disable purchase, sales, and transfer-order synchronization independently | | Sync selection | Use an optional NetSuite sync flag; filter by ship method or transaction-number patterns | | Ship methods | Configure include or exclude lists; apply each rule to selected order types | | Transaction numbers | Exclude orders using starts-with, ends-with, contains, or does-not-contain rules | | Status mapping | Keep Owlery defaults or override individual NetSuite statuses by transaction type | | Pickup and delivery dates | Select standard or custom fields separately for each order type, or disable a date when it doesn't apply | | Pickup addresses | Read a standard address, custom HTML address, NetSuite Location, or vendor/customer address-book entry | | Address fallback | Fall back through order, location, entity, and custom-location data when the preferred source is incomplete | | Classification routing | Map a classification or any parent classification to parcel or freight mode | | Department routing | Map a department hierarchy to parcel or freight mode, optionally by order type | | Subsidiary routing | Route records from one connection into the correct child organization using the order subsidiary | | Sales channel mapping | Read a sales channel from the order or linked customer and map it to GL codes | | SKU mapping | Use the NetSuite item SKU or override it with a configured transaction-line field | | Notes | Choose the body and line fields used for operational and BOL instructions | | Item types | Use Owlery's default item set or choose the exact NetSuite record types to include | | Facility identity | Control whether the NetSuite Location ID is used as the stable facility source ID | | Weight and packaging | Read weight from item records; build configurable packaging relationships | | PO splitting | Split one PO into stable child shipments using configured quantity fields on each line | | Landed cost | Select the NetSuite cost category; allocate freight by weight, quantity, or line value | | Write-back strategy | Enable individual fulfillment, receipt, load ID, delivery date, and freight-booked actions | | Write-back triggers | Trigger by load event, order event, order type, or order tag | | Lot behavior | Use source lot assignments, warehouse lot data, NetSuite auto-assignment, or explicit inventory detail | ## Status, classification, and department rules Owlery includes default status mappings for purchase, sales, and transfer orders. You can override any mapping when your NetSuite process interprets a standard status differently. Classification and department rules support NetSuite hierarchies. A rule can match a value directly or match one of its parent records — this lets you apply one rule to an entire branch of your NetSuite structure instead of configuring every child value individually. For example, one parent classification can identify parcel orders while all unmatched classifications remain freight orders. ## Subsidiaries and multiple organizations A single NetSuite connection can route orders to different Owlery child organizations using the NetSuite subsidiary ID. Owlery validates that every configured destination belongs to the same organization family. Incremental synchronization checks the complete organization family so child-organization activity is never missed. You can also connect multiple NetSuite accounts when separate credentials or account boundaries are the better fit. ## Lots, units, and packaging Owlery resolves the transaction unit against the item's NetSuite Units Type record. When NetSuite returns an unavailable or unsupported unit, Owlery preserves the line using a safe default and reports the condition for review. For lot-controlled inventory, Owlery can: * Read issue and receipt inventory numbers * Preserve expiration dates * Split one NetSuite line into multiple Owlery item lines when it contains multiple lots * Recombine those item lines by original NetSuite line during write-back * Match lots by item and location * Send explicit inventory assignments only when the account requires them This distinction matters because accounts with Inventory Status enabled can require different fulfillment behavior from accounts using lot tracking without Inventory Status. ## Authentication and permissions Owlery authenticates with NetSuite token-based OAuth 1.0 using the five values you generate during setup. [Connecting NetSuite](/shippers/netsuite/connect) covers the credentials, the recommended integration role, and how permissions are scoped to the record types and write-back actions you enable. # Connecting NetSuite Source: https://help.owlery.ai/shippers/netsuite/connect The one-time credential setup — what to create in NetSuite, what the setup never involves, and the role configuration we recommend. Connecting NetSuite is a one-time setup task. It uses NetSuite's built-in token-based authentication, so there is no development work, nothing to install, and nothing to maintain afterward. **Would you rather we walk you through it?** Most customers do this on a short screen share with our team. Email [support@owlery.ai](mailto:support@owlery.ai) and we'll set one up. The steps below are here if you'd prefer to work through it yourself or hand it to your NetSuite partner. ## What this setup does not involve * **No SuiteScript.** Owlery uses NetSuite's standard SuiteTalk REST and SuiteQL interfaces. * **No managed bundle.** Nothing is installed into your NetSuite account. * **No user seat.** Owlery authenticates as an integration, not as an employee. * **No data export.** Owlery reads your account directly. You never assemble spreadsheets of sample records for us. * **No ongoing maintenance.** Once the tokens exist they keep working, and Owlery monitors the connection. ## What you'll create Setup produces five values that you hand to Owlery: | Value | Where it comes from | | --------------- | ---------------------------------------------------- | | Account ID | Company information | | Consumer Key | The integration record | | Consumer Secret | The integration record | | Access Token | The access token (NetSuite labels this **Token ID**) | | Token Secret | The access token | NetSuite displays the consumer secret and the token secret **only once**, at the moment it generates them. Copy both before leaving the page. If they're lost, you'll need to generate replacements. ## Setup steps Go to `Setup → Company → Enable Features → SuiteCloud`. Enable **REST Web Services** and **Token-Based Authentication**, then save. Go to `Setup → Integration → Manage Integrations → New`. Name it something recognizable such as `Owlery`, enable **Token-Based Authentication**, and save. NetSuite shows the **Consumer Key** and **Consumer Secret** on the confirmation screen. Copy both now. Create a role for Owlery and assign it to the user who will own the connection. Owlery gives you the exact permission list for your workflow. It depends on which order types and write-back actions you enable, so we scope it to what you actually need rather than asking for broad access. Go to `Setup → Users/Roles → Access Tokens → New`. Select your Owlery integration, the user, and the role you just created, then save. NetSuite shows the **Token ID** and **Token Secret** once. Copy both. Go to `Setup → Company → Company Information`. Your Account ID is listed there. Sandbox accounts include a suffix such as `_SB1`. Enter them under `Settings → Integrations` and click **Test & Save**, or send them to your Owlery contact and we'll complete the connection for you. NetSuite's exact menu labels vary slightly by account version and enabled features. If something isn't where you expect it, our team can find it with you. ## Recommended: use a dedicated integration role Create a NetSuite role used only by Owlery rather than attaching the token to an existing employee role. * Permissions stay scoped to the records the integration actually uses, so the connection can't reach data it doesn't need. * The role survives staff changes. Someone leaving the company doesn't break your freight sync. * NetSuite's audit trail attributes every Owlery request to one identifiable role. * Permissions can be widened one record type at a time as you enable more workflows. Start with read permissions only. Add write permissions later, if and when you decide to turn on [write-back](/shippers/netsuite/writing-back). ## Permissions The role needs read access to the record types you want to synchronize, plus write access for any fulfillment, receipt, or order-field update you enable. Optional features may need supporting records such as locations, employees, classifications, departments, cost categories, inventory numbers, and units of measure. Owlery identifies the specific permissions your workflow requires rather than asking for blanket access. ## Verifying the connection Owlery verifies access to purchase orders, sales orders, and transfer orders separately during testing. If one record type is missing a permission, we tell you which one — you won't get a single unhelpful failure for the whole connection. What Owlery pulls in once the connection is live. # NetSuite Integration Source: https://help.owlery.ai/shippers/netsuite/overview Three things from your team. Owlery handles everything else. Owlery connects to NetSuite through the SuiteTalk REST API and SuiteQL. We pull your orders and item data into Owlery automatically, then design and configure the write-back workflows that fit your business — so your team doesn't have to. **No NetSuite admin on staff? No problem.** Most Owlery customers connect NetSuite without a dedicated NetSuite administrator or IT team. You provide credentials, we handle the rest. **Where to find it:** `Settings → Integrations` ## What Owlery handles Everything else: * **Discovering your configuration**: subsidiaries, custom fields, statuses, units of measure, item types, address formats, and operating workflows. * **Designing the integration**: which records to sync, how to map fields, how to route subsidiaries, and which write-back events to enable. * **Building and testing**: configuring mappings, filters, routing, and write-back strategies; testing normal, partial, and exception scenarios. * **Rolling out and monitoring**: coordinating the go-live, backfilling historical data if needed, and monitoring synchronization going forward. * **Adapting when things change**: when your NetSuite fields, roles, subsidiaries, or workflows evolve, Owlery updates the integration. Owlery adapts to *your* NetSuite — we don't ask you to change how your team uses it. ## Two parts of the integration The NetSuite integration has two distinct parts, and they can be enabled independently: Owlery pulls orders, items, and facilities from NetSuite automatically. This is hands-free after credentials are connected — no ongoing work from your team. When you're ready, Owlery designs a best-practice system for creating fulfillments, receipts, and freight updates in NetSuite. We recommend what to enable based on your workflows. Most teams start with read-only synchronization. Write-back strategies are introduced after your team validates the inbound data — there's no pressure to enable everything at once. ## Getting started Owlery needs three things from you — credentials, a few sample transactions, and a short confirmation call. Everything else is on us. You provide five token-based values — Account ID, Consumer Key, Consumer Secret, Access Token, and Token Secret. [Connecting NetSuite](/shippers/netsuite/connect) walks through generating them, and we're happy to do it with you on a screen share. Owlery verifies access and begins account discovery right away. Share two or three representative PO, SO, or TO numbers. Owlery reviews your transactions, custom fields, statuses, and workflows, then presents a recommended configuration — nothing is needed from your team during this stage. Your team reviews the recommendation in a short call and confirms it matches how you actually operate. We adjust anything that doesn't fit. Owlery enables the configuration, validates representative records, monitors the first syncs, and adjusts as needed. Straightforward accounts move through these stages quickly — often within the first week or two. Accounts with many subsidiaries, heavy customization, or complex lot requirements spend longer in the design stage. Owlery tells you what to expect once we've seen your account, and the waiting is on our side rather than yours. ## Frequently asked questions No. You need someone who can generate API credentials — that's often an existing NetSuite user with an admin role, a bookkeeper, or even your NetSuite partner. Owlery handles everything after that. Almost never. Owlery maps your existing records, fields, statuses, and workflows. If a small optional change would improve things, we explain the benefit and the minimal effort involved — but it's your call. Absolutely. Inbound synchronization works independently. Individual write-back strategies can be added later, one at a time, as your team gets comfortable. One connection can route orders from different NetSuite subsidiaries into the correct Owlery organizations. Separate connections are also supported when account boundaries require them. Owlery does. We own the configuration and work with your designated contact when anything in NetSuite changes. Yes. Owlery supports full re-syncs and exact-reference lookups for orders outside the normal selection window. Need help planning your NetSuite connection? Email [support@owlery.ai](mailto:support@owlery.ai) and include a few representative transaction numbers. # Reading Data from NetSuite Source: https://help.owlery.ai/shippers/netsuite/reading-data How Owlery automatically pulls orders, items, and facilities from NetSuite — hands-free after credentials are connected. Once your NetSuite credentials are connected, Owlery begins pulling data automatically. There is no manual mapping, no CSV uploads, and no recurring work from your team. Owlery discovers your account configuration, converts NetSuite records into Owlery shipments and items, and keeps everything in sync on an ongoing basis. Reading data from NetSuite is the simplest part of the integration. Owlery handles it almost entirely hands-free — your team just provides credentials and confirms the initial setup. ## How it works Owlery uses token-based OAuth 1.0 with HMAC-SHA256 signed requests. Your credentials are never stored in plain text. We read your classifications, departments, locations, cost categories, units of measure, and item records to understand how your NetSuite is configured. Owlery retrieves new and changed records through paginated, incremental syncs. Only what's changed since the last sync is pulled — we don't repeatedly import your full account. Each NetSuite record is transformed into the facilities, stops, dates, items, references, and statuses your Owlery workflows need. Invalid data is flagged for review, not silently accepted. ## Orders Owlery supports three NetSuite transaction types: | NetSuite record | How Owlery uses it | | --------------- | --------------------------------------------------------------------------------------- | | Sales Order | Creates a customer shipment with origin, destination, dates, references, and line items | | Purchase Order | Creates a supplier shipment; can identify outsourced purchase-order lines | | Transfer Order | Creates an internal inventory movement between facilities | Each order type can be enabled or disabled independently. Owlery recommends which ones to turn on based on the transactions it finds in your account. From each order, Owlery can synchronize: * Internal ID, transaction number, external ID, and reference numbers * Statuses (mapped to Owlery equivalents based on your workflows) * Created and last-modified timestamps * Creator, employee, or sales representative email * Customer, vendor, subsidiary, classification, department, and sales channel * Pickup and delivery facilities, addresses, and dates * Header notes and line-level handling notes * Line items with SKU, quantity, fulfilled/received quantity, unit, rate, and amount * Lot or inventory assignments and expiration dates * Ship method and other configured custom fields ## Item master Owlery synchronizes your item catalog alongside orders. The default configuration recognizes more than 15 item types — inventory, assembly, kit, non-inventory, service, shipping, and other charge items — and the included types can be customized for your account. Item data can include: * SKU, name, description, and NetSuite record type * Base and transaction units of measure * Weight and weight unit * Case, carton, each, and pallet packaging relationships * Cases per pallet (including TI × HI calculations) * Temperature ranges for refrigerated products * Lot numbers and expiration dates ## Addresses and facilities Addresses are often the most account-specific part of a NetSuite setup. Owlery resolves facilities from whichever source your account uses: * The shipping address on the order itself * A NetSuite Location record * A vendor or customer address-book entry * A custom body field * A `
`-delimited address in a custom field * A linked custom location record Different sources can apply to sales, purchase, and transfer orders. If the preferred source is missing, Owlery falls back through configured alternatives while preserving facility identity. Invalid addresses are flagged for review. ## Selection and filtering Not every NetSuite record needs to come into Owlery. The integration can filter using: * An optional NetSuite sync flag on the transaction * Ship method include/exclude lists * Transaction-number pattern matching (starts-with, ends-with, contains, or excludes) * Status mapping rules * Subsidiary routing rules * Classification and department hierarchy matching Owlery recommends the smallest set of filters that captures your intended workflow. ## Reliability and governance Owlery is designed around NetSuite's API behavior: * **Incremental syncs** only pull new and modified records * **Request pacing** respects governance limits and spaces concurrent calls * **Smart retries** back off on concurrency rejections with exponential delay and jitter * **Stable identities** preserve child-order relationships across re-syncs * **Structured errors** surface actionable NetSuite details for troubleshooting * **Reference lookup** lets an authorized user manually import a specific transaction outside the normal filter Owlery monitors sync health continuously. If something breaks — a permission change, a NetSuite update, an API hiccup — we catch it and resolve it before your team needs to get involved. # Writing Back to NetSuite Source: https://help.owlery.ai/shippers/netsuite/writing-back Owlery designs a best-practice write-back system tailored to your NetSuite workflows — fulfillments, receipts, landed cost, and more. Write-back is where Owlery's NetSuite expertise makes the biggest difference. Rather than asking your team to configure fulfillment logic, receipt behavior, and field mappings, Owlery designs a recommended write-back system based on how your NetSuite account actually works — then implements and maintains it for you. **This is the part we design for you.** Owlery reviews your existing fulfillment and receipt patterns, then recommends the write-back strategies that match your business process. Your team confirms the recommendation — we build and maintain everything. ## How Owlery approaches write-back Write-back is optional and modular. Each action below is an independent strategy that can be enabled or disabled on its own. Most teams don't need all of them — Owlery recommends the combination that fits your workflow. We review your existing fulfillment and receipt records, shipment-related custom fields, lot and location requirements, and the write-back capabilities your NetSuite account supports. Based on what we find, we propose which write-back strategies to enable, which triggers to use, and how to handle edge cases like partial shipments, multi-lot lines, and landed cost allocation. You review the recommendation and tell us whether it matches the intended business outcome. We adjust anything that doesn't fit. We configure the strategies, test against representative and exception scenarios, enable the agreed behavior, and monitor the first records through. ## Available write-back strategies | Owlery event | What happens in NetSuite | | --------------------------------- | ------------------------------------------------------------- | | Sales order ready for fulfillment | Transforms the Sales Order into an Item Fulfillment | | Transfer shipment leaves origin | Transforms the Transfer Order into an Item Fulfillment | | Transfer shipment arrives | Transforms the Transfer Order into an Item Receipt | | Purchase shipment arrives | Transforms the Purchase Order into an Item Receipt | | Load is picked up | Writes the Owlery load number to configured transaction lines | | Load is delivered | Writes the delivery timestamp to the source transaction | | Freight is booked | Marks the source transaction as freight booked | | Item receipt is created | Adds allocated freight as landed cost (when configured) | Fulfillment and receipt payloads include line quantities, item and header locations, tracking numbers, shipment dates, transaction dates, and lot assignments. Owlery reads the original NetSuite lines before writing back so every update uses the correct NetSuite line and item identities. ## Best-practice recommendations Owlery brings deep experience across dozens of NetSuite implementations. Here's what we typically recommend: ### Start read-only, then layer in writes Validate your inbound data before enabling write-back. This lets your team build confidence in the integration without any risk of creating incorrect records in NetSuite. ### Enable one strategy at a time Each write-back action is independent. Rather than enabling everything at once, introduce them sequentially so each strategy can be validated on real transactions before the next one is turned on. ### Let Owlery handle lot complexity Lot-controlled inventory introduces significant complexity. Owlery can read issue and receipt inventory numbers, preserve expiration dates, split one NetSuite line into multiple Owlery item lines when it contains multiple lots, then recombine them correctly during write-back. We handle the difference between accounts with Inventory Status enabled and those using lot tracking without it. ### Use landed-cost allocation for purchase receipts When enabled, Owlery posts the booked freight cost to NetSuite Item Receipts using your chosen cost category and allocation method: * **By weight**: distributes cost by line weight, normalizing mixed units * **By quantity**: distributes cost by received quantity * **By value**: distributes cost by extended line value Owlery reconciles rounding so allocated amounts always equal the total freight cost exactly. If NetSuite has already created the receipt, Owlery locates the existing record and updates its landed-cost fields. ## Write-back triggers Strategies can be triggered by different events depending on your workflow: * Load events (pickup, delivery, freight booked) * Order events (status changes, tag updates) * Order type (apply different strategies to POs vs SOs vs TOs) * Order tags (target specific workflows without changing NetSuite fields) Owlery recommends the trigger combination that minimizes manual intervention and matches your team's existing expectations for when NetSuite records should update. ## Safe writes by design Owlery takes extra care when writing to your system of record: * **Pre-read validation**: Owlery reads the original NetSuite lines before every write to ensure correct identities * **Concurrency protection**: only retries requests that NetSuite blocked before processing; validation failures are never blindly retried * **Structured error reporting**: preserves NetSuite error details so issues are actionable, not opaque * **Governance awareness**: paces requests within NetSuite's API limits Write-back is entirely optional. Many teams run successfully with read-only synchronization for months or permanently. There's no pressure to enable writes before you're ready. # Order Settings Source: https://help.owlery.ai/shippers/order-settings Control what information your orders carry when they're created, imported, or sent to your warehouse. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Orders` Order settings control what information your orders carry. They change what your team is asked for when creating an order, what Owlery accepts from a CSV upload, and what gets passed on to your warehouse. ## Order Production Date **Value:** On / Off **What it does:** Adds a production date to your orders — the date the goods were made or packed, as distinct from the date they ship. Turning it on does three things at once: * **Order form**: a production date field appears when someone creates an order by hand. * **CSV uploads**: the production date column is accepted when you upload orders from a CSV. * **Warehouse**: the production date is included in the order details Owlery sends to your warehouse. **When you'd turn it on:** If you ship anything where age matters — food, beverage, pharmaceuticals, cosmetics, or anything with a shelf life — and your warehouse or your customer needs the production date to pick the right stock. **When to leave it off:** If production date isn't part of how you ship. Leaving it off keeps the order form shorter and simpler for your team. # Orders Source: https://help.owlery.ai/shippers/orders Your POs and SOs — the starting point for every shipment. **Where to find it:** `Orders` Your POs and SOs — the starting point for every shipment. ## Getting orders in * **Integration sync**: orders pull in automatically from a connected ERP, WMS, or EDI; trigger a manual sync any time. * **CSV upload**: fill the Order Template and upload from the table toolbar. * **+ New Order**: create one at a time (Purchase, Sales, or Transfer). ## Working the Orders table * Switch between **Table, Item Summary,** and **Calendar** views. * Filter by status chip; **Show All** reveals every status. * Click any row to open the **Order Drawer** with full detail across tabs. ## Moving fast with bulk actions Click **Select** in the toolbar above the orders table, then check the orders you want to act on. Three bulk action buttons appear: * **Edit**: update fields like dates or details across all selected orders at once. * **Quote**: request pricing for every selected order in a single step. * **Send**: tender the selected orders to carriers immediately. From any open order you can also hit **Quote** to jump straight to pricing with that order pre-loaded. # QuickBooks Online Integration Source: https://help.owlery.ai/shippers/quickbooks Connect your accounting workflow while Owlery handles the mapping and controls. Owlery connects to QuickBooks Online through the Intuit API. We can synchronize a supported Estimate workflow, map QuickBooks Items, create freight Purchase Orders from booked quotes, and support a specialized connected invoice workflow. Owlery learns how your Customers, Items, Estimates, Vendors, accounts, and accessorials relate. We recommend the accounting mappings; your team confirms the intended result. **Where to find it:** `Settings → Integrations` ## Three parts of the integration Synchronize supported Estimates and Items through QuickBooks change tracking. Create or update Estimates and freight Purchase Orders, plus review the specialized invoice workflow. Review Customer, Item, Vendor, AP-account, GL-code, and accessorial mappings. ## Getting started A QuickBooks administrator [connects QuickBooks Online to Owlery](/shippers/quickbooks/connect). The administrator selects the company and approves access; Owlery handles the OAuth 2.0 connection. Share examples of the Estimates, Items, Vendors, Purchase Orders, or Invoices relevant to your selected workflow. Owlery presents the recommended Customer, Item, Vendor, AP-account, GL-code, and accessorial mappings. Your team confirms the operational and accounting result. Owlery validates the agreed scenarios, enables the workflow, and monitors the first records. Need help planning your QuickBooks connection? Email [support@owlery.ai](mailto:support@owlery.ai). # QuickBooks Configuration Reference Source: https://help.owlery.ai/shippers/quickbooks/configuration Estimate, Customer, Item, Vendor, account, and freight write-back mappings. Owlery inspects the connected QuickBooks company, proposes the accounting mappings, and maintains the approved configuration. Your team does not need to assemble these IDs before discovery. Owlery recommends the mapping and asks you to confirm the accounting result. | Area | Available controls | | -------------------------- | ----------------------------------------------------------------------- | | Overall synchronization | Enable or disable background synchronization | | Estimate synchronization | Enable or disable the supported Estimate workflow | | Historical refresh | Run a paginated full Estimate scan for an intentional re-sync | | Quote write-back | Enable or disable freight Purchase Order write-back | | Cross-system write-back | Allow an order from another source to create a freight PO in QuickBooks | | Carrier mapping | Map Owlery carrier or broker profiles to QuickBooks Vendor IDs | | Freight coding | Map Owlery GL codes to QuickBooks freight Item IDs | | AP account | Select the AP account for new freight Purchase Orders | | Accessorial coding | Map Owlery line-item categories to QuickBooks Item IDs | | Customer and Item matching | Match Customers by display name and Items by SKU | ## Mapping relationships | Owlery value | QuickBooks destination | | ------------------------- | ---------------------- | | Carrier or broker profile | Vendor ID | | Order GL code | Freight Item ID | | Integration setting | AP account ID | | Accessorial category | Accessorial Item ID | Owlery validates representative Customers, Items, Vendors, accounts, and accessorial categories before enabling write-back. # Connect QuickBooks Online to Owlery Source: https://help.owlery.ai/shippers/quickbooks/connect Select and authorize your QuickBooks company while Owlery handles the OAuth 2.0 connection. Connecting QuickBooks Online is a one-time approval. You do not need to create a developer app or copy a Client ID or Client Secret. **Where to find it:** `Settings → Integrations` OAuth 2.0 means Intuit asks you to approve Owlery without giving Owlery your QuickBooks password. You can disconnect the access later from QuickBooks or Owlery. ## Before You Start You need: * QuickBooks Online administrator access * Your Owlery sign-in * The name of the QuickBooks company you want to connect Intuit may show more than one company after you sign in. Select the company whose accounting records should synchronize with Owlery. ## Connect QuickBooks Online In Owlery, go to `Settings → Integrations`. Find **QuickBooks Online** and click **Connect**. Owlery sends you to Intuit's secure sign-in page. Sign in with a QuickBooks administrator account. If your browser blocks the new page, allow pop-ups for Owlery and click **Connect** again. If Intuit asks you to choose a company, select the QuickBooks company you want Owlery to use. Review the request and click the button to connect Owlery. Intuit sends the approval directly to Owlery; you do not need to copy a code or token. Intuit sends you back to Owlery. Confirm that QuickBooks Online shows **Connected** and that the displayed company is correct. ## What Owlery Handles Owlery maintains the Intuit application, stores the company-specific tokens securely, and refreshes access automatically. Your team does not need to maintain OAuth credentials. Intuit explains the underlying process in [Authentication and authorization](https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization). That guide is for developers; you only need to complete the approval steps above. ## Troubleshooting Confirm that the Intuit account has administrator access to that company. Sign out of Intuit, sign in with the correct administrator account, and try again. Ask a QuickBooks company administrator to complete the connection. Standard users may not be allowed to approve an app. Disconnect QuickBooks Online in Owlery and repeat the steps. Select the intended company when Intuit prompts you. Start again from `Settings → Integrations` and complete the approval in one browser session. If it still fails, send the error message to [support@owlery.ai](mailto:support@owlery.ai). See which QuickBooks records Owlery synchronizes after authorization. # Reading Data from QuickBooks Online Source: https://help.owlery.ai/shippers/quickbooks/reading-data How Owlery synchronizes supported Estimates and Items through QuickBooks change tracking. QuickBooks Online does not expose a native sales-order record like many ERPs. Owlery's supported workflow represents the accounting-side customer order as a QuickBooks Estimate linked to an originating Owlery order. ## Estimate synchronization Owlery reads the Estimate ID, synchronization token, status, Item identities, SKU or description, quantity, unit price, and amount. The linked Owlery order retains its originating facilities, customer, and operational context. | QuickBooks Estimate status | Owlery status | | -------------------------- | ------------- | | Pending | Open | | Accepted | Confirmed | | Closed or Converted | Closed | | Rejected | Cancelled | Estimate lines are currently interpreted as cases. Owlery confirms whether this matches your item model during discovery. Owlery does not import every unrelated QuickBooks Estimate as a new freight order. The workflow synchronizes Estimates that match an originating Owlery order. ## Change tracking and reliability * **Incremental Change Data Capture** reads changed Estimates and Items. * **Cursor overlap** includes one minute around the prior successful sync. * **Lookback control** stays within QuickBooks' 30-day Change Data Capture limit. * **Intentional full refresh** uses a paginated Estimate query instead of the limited change window. * **Deletion reconciliation** marks deleted Estimates and invalidates deleted Items. * **Connection-scoped caching** isolates Item data between QuickBooks companies. * **Request pacing** spaces QuickBooks API calls. * **Change-volume monitoring** warns as a response approaches QuickBooks' object limit. ## Authentication A QuickBooks administrator authorizes Owlery through Intuit OAuth 2.0 and selects the company to connect. Owlery stores the company ID and account-specific access and refresh tokens. Token refresh is serialized per connection to prevent concurrent rotation. # Writing Back to QuickBooks Online Source: https://help.owlery.ai/shippers/quickbooks/writing-back Supported Estimate, freight Purchase Order, and specialized invoice workflows. QuickBooks write-back is workflow-specific. Owlery studies the connected company, recommends the applicable actions, and enables only the approved paths. ## Order-to-Estimate workflow Owlery can create or update a QuickBooks Estimate from an existing order. The payload can include: * Owlery order number as the QuickBooks document number * Customer matched by QuickBooks display name * Transaction date and cancellation status * Items resolved by SKU * Quantity, unit price, amount, and description * Source order number as a custom field * Destination address and expiration date * Operational history in the customer memo The supported workflow can create a missing Customer by display name. Items must resolve to usable QuickBooks records by SKU. Updates include the Estimate ID and synchronization token. ## Freight Purchase Orders When freight is booked, Owlery can create or update a QuickBooks Purchase Order using approved Vendor, AP-account, freight-Item, and accessorial mappings. The PO contains one freight line per linked order and can add separate accessorial or other-charge lines. Owlery treats line haul, fuel surcharge, and discounts as freight and validates that the signed line total matches the quote total. When a quote covers multiple weighted orders, Owlery normalizes weight units and allocates freight across orders. It preserves the exact total and records the PO reference on the related quote and load. Before writing, Owlery queries QuickBooks by a deterministic document number. It creates a PO when none exists, updates one match, and stops for review if multiple matches exist. ## Specialized invoice workflow Owlery includes a specialized workflow for an Estimate linked to an Invoice and a supported trading-partner EDI connection. It can read the Invoice, Items, and payment term, then send the supported EDI 810 after confirming the order is closed and an invoice transaction has not already been sent. This is not a general invoice export for every QuickBooks company. ## Safe writes by design * OAuth refresh is locked per connection. * Estimate updates use QuickBooks synchronization tokens. * Freight allocation must reconcile to the booked quote total. * Deterministic document numbers reduce duplicate Purchase Orders. * Multiple matching records stop for review instead of being guessed. * API calls and write-back results are monitored by workflow. # Quote Response Date Warnings Source: https://help.owlery.ai/shippers/quote-response-date-warnings How Owlery compares a carrier's estimated dates against the dates you requested. **Where to find it:** `Quotes → click any quote row → Details tab` When you review carrier responses to a quote, each response shows the carrier's estimated pickup and dropoff dates. If those dates do not fit the dates you requested on the order, Owlery shows a calendar warning beside that response. The warning is informational, so you can still select the response after reviewing the dates. ## Where dates appear In the response list, the **Transit** column shows the pickup date, an arrow, and the dropoff date, along with the estimated transit time in business days. When the response gives a range of business days, the dropoff date is shown as a range. Open a response to see the **Estimated Dates** table, which lists each stop as `Stop N of M`, its type, and the estimated date or date range. Owlery shows dates in one of two formats: * A single date, such as `July 10`. * A date range, such as `July 10 – July 12`. ## How Owlery compares dates Owlery matches each stop in the response to the corresponding stop on your order, using stop number and stop type. If a stop has no estimated date, Owlery does not show a warning for it. Your ordered dates set the allowed range. The carrier's entire estimated range must fit inside the ordered range. This rule is the same for pickup and dropoff stops. * A date without a time includes that entire calendar day in the ordered stop's time zone. * A date-only end date includes the full end date, through the end of that day. * A date with a time is compared as that exact time. * If a range has only one boundary, Owlery treats it as a single date or exact time. Owlery shows a warning if any part of the estimated range falls before or after the ordered range. An exact match on either boundary counts as fitting. ## Single-Day Examples | Ordered dates | Carrier's estimated dates | Result | | ------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------- | | July 10 | July 9 | Calendar warningWarning: the estimate falls before the ordered day. | | July 10 | July 10 | No warning: both refer to the same full calendar day. | | July 10 | July 10 at 1:01 AM | No warning: the estimate is during the ordered calendar day. | | July 10 | July 11 | Calendar warningWarning: the estimate falls after the ordered day. | ## Date-Range Examples | Ordered dates | Carrier's estimated dates | Result | | ----------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | July 10 – July 12 | July 10 – July 12 | No warning: the ranges match. | | July 10 – July 12 | July 11 | No warning: the estimate is inside the ordered range. | | July 10 | July 10 – July 11 | Calendar warningWarning: part of the estimated range falls after the ordered day. | | July 10 | July 9 – July 10 | Calendar warningWarning: part of the estimated range falls before the ordered day. | | July 10 – July 12 | July 9 – July 12 | Calendar warningWarning: part of the estimate falls before the ordered range. | | July 10 – July 12 | July 10 – July 13 | Calendar warningWarning: part of the estimate falls after the ordered range. | | July 10 – July 12 | July 12 at 11:59 PM | No warning: a date-only end date includes the entire end date. | | July 10 – July 12 | July 13 at 12:00 AM | Calendar warningWarning: the estimate falls after the date-only end date. | ## Find the affected stop Hover over the calendar warning beside the response. The tooltip identifies the stop number and type and shows both the estimated and requested dates. If the dates do not work for your shipment, review the affected order stop or choose another response with dates that fit the requested range. # Quotes Source: https://help.owlery.ai/shippers/quotes Find, filter, and follow your quotes — plus what every status and drawer tab means. Below the create form, the **Quotes** table is your home base for everything you've sent — what's still open, what's been quoted, and what's already booked. ## The Quotes table Each row is one quote. | Column | What it shows | | --------------------------- | ------------------------------------------------------------------------------------------------------ | | **ID** | Short quote identifier, like `Q-1234`. | | **Status** | Where the quote stands (see statuses below). | | **# Quotes** | A breakdown of responses: **green** = quoted, **orange** = pending or expired, **grey** = unavailable. | | **Tendered At** | The price of the accepted or tendered response. | | **Equipment** | The equipment type you requested. | | **Pickup / Dropoff** | Locations and dates. | | **Items** | A quick freight summary. | | **Created At / Created By** | When it was made and by whom. | | **Action** | The re-quote button to re-send the same request. | Filter the table by status, equipment type, pickup or dropoff date, or who created the quote. You can also sort by created, pickup, or dropoff date. Click **Download CSV** to export whatever you're currently viewing. ## Quote statuses | Status | What it means | | -------------------- | --------------------------------------------------------------------- | | **Open** | Request sent, waiting on responses. | | **Quoted** | At least one carrier rate has come in. | | **Tendered** | A carrier was selected and the load was tendered. | | **Accepted** | The carrier accepted the tender. | | **Carrier Selected** | A carrier was chosen but not yet fully tendered (two-step tendering). | | **Cancelled** | The tender was cancelled. | ## What's in the quote drawer Click any row to open the drawer. Besides the **Details** tab — where you review responses and tender — you'll find: * **Lane History**: a historical rate chart for this exact lane (origin–destination), so you can gauge whether a quote is competitive. * **Order Items**: the order line items tied to this quote. * **Documents**: files attached to the tendered response (BOL, packing list, shipping label, and so on), ready to download. * **Tender History**: the full tender lifecycle, including cancellations, re-tenders, and load status if a load was created. * **Linked Items**: everything connected to this quote: related orders, loads, and other records. ## Re-quote an existing quote Want to send a fresh request with the same details? You can re-quote two ways: Click the **re-quote** button (↺) in the **Action** column of the table, or open the quote drawer and click **Re-quote**. The create form at the top of the page fills in with the original quote's route, shipment details, and carrier selections. Change anything you need, then submit. ## Handy to know * **Jump straight here**: use the search bar at the top of any page and type `rate quote` or `quotes` to land on the Quotes page. * **New quotes are easy to spot**: they carry a **New** badge for five minutes after you create them. * **Responses refresh on their own**: a spinning **Quoting…** indicator shows in the **# Quotes** column while carrier responses are still coming in. *** Stuck on something? Email [support@owlery.ai](mailto:support@owlery.ai) # Quoting Settings Source: https://help.owlery.ai/shippers/quoting Set the values that prefill your quotes and choose which carriers get to price them. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Quoting` Carriers need weight, dimensions, freight class, and commodity to price a shipment. Your team rarely has all of it to hand. These settings tell Owlery what to assume, so quotes go out complete instead of half-filled. Everything in **Shipment Defaults** is a fallback: Owlery uses the real value whenever it has one, and only reaches for your default when the real value is missing. Two settings are exceptions and change the calculation itself — Freight Class with its override switch on, and Pre-2025 Freight Class Rules. ## Settings in This Group | Group | Settings | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **[Shipment Defaults](#shipment-defaults)** | [Pallet Dimensions](#pallet-dimensions), [Preferred Pallet Dimensions](#preferred-pallet-dimensions), [Fractional Pallet Height Padding](#fractional-pallet-height-padding), [Pallet Weight](#pallet-weight), [Full Pallet Weight](#full-pallet-weight), [FTL Weight](#ftl-weight), [Reefer Settings](#reefer-settings), [Commodity Description](#commodity-description), [Cargo Value](#cargo-value), [Default Load Notes](#default-load-notes), [Freight Class](#freight-class), [Pre-2025 Freight Class Rules](#pre-2025-freight-class-rules) | | **[Carrier Quoting](#carrier-quoting)** | [Preferred Brokers](#preferred-brokers), [Additional Rates](#additional-rates), [Competitive Bid Carrier Visibility](#competitive-bid-carrier-visibility), [Carrier SCAC Blacklist](#carrier-scac-blacklist), [Weight/Quantity Threshold](#weightquantity-threshold) | | **[Quote Form Fields](#quote-form-fields)** | [Stop Requirements](#stop-requirements), [Pickup Date Fallback](#pickup-date-fallback), [Allow Same-Day Pickup](#allow-same-day-pickup), [Dropoff Date Fallback](#dropoff-date-fallback), [Remove Dimension Field](#remove-dimension-field), [Remove Date Field](#remove-date-field), [Appointment Time Increment](#appointment-time-increment) | | **[Quote Date Warnings](#quote-date-warnings)** | A single setting — see the section | | **[Dock Scheduling](#dock-scheduling)** | [Show Same Order Appointment Action](#show-same-order-appointment-action) | | **[API](#api)** | [Skip External Quote Deduplication](#skip-external-quote-deduplication) | ## Shipment Defaults ### Pallet Dimensions **What it does:** Sets the length × width × height used when the items being shipped have no dimensions of their own. **When you'd set it:** If you ship on standard pallets. It's the most useful default here — LTL carriers need dimensions to price at all. ### Preferred Pallet Dimensions **What it does:** Gives your team a short list of pallet sizes to pick from while quoting, instead of typing measurements each time. **When you'd set it:** List your standard configurations — say a 48×40, a half pallet, and an oversize — and picking becomes one click. Unlike **Pallet Dimensions**, which is a silent fallback, these are a menu your team chooses from on purpose. ### Fractional Pallet Height Padding **What it does:** Adds extra height when Owlery calculates a part-full pallet from your item data, since a half-height stack isn't exactly half the height once you count the pallet, packaging, and stretch wrap. **When you'd set it:** Only if you use item-driven pallet calculations and find the computed heights come out consistently short. ### Pallet Weight **What it does:** Sets the weight of an empty pallet, added on top of the weight of the goods. **When you'd set it:** Always, if you ship palletized. Match it to the pallets you actually use — a standard wooden pallet is typically 30–50 lb. Leave this out and your quoted weight is under the weight the carrier actually hauls. That gap comes back as a re-weigh charge on the invoice. ### Full Pallet Weight **What it does:** Sets the total weight assumed for one loaded pallet when Owlery doesn't know what the items weigh. **When you'd set it:** If your pallets are consistent. **When to leave it unset:** If your product mix varies a lot — an unset value is better than a number that's often wrong. ### FTL Weight **What it does:** Sets the weight assumed on a full-truckload quote when item weights are unknown. **When you'd set it:** FTL is priced by the lane rather than exact weight, so a round number is fine — many shippers set this near the legal maximum for a full trailer. ### Reefer Settings **What it does:** Prefills the target temperature and how it should be maintained on refrigerated shipments. **When you'd set it:** If you ship at a consistent temperature. It means a required temperature is never left blank on a load that needs one. ### Commodity Description **What it does:** Provides a plain-English description of what you ship — for example "Packaged food products" — used on quotes, loads, and documents when nothing more specific is available. **When you'd set it:** Whenever your item data doesn't already describe the freight. A carrier or driver reading a document should be able to tell roughly what's on the truck. ### Cargo Value **What it does:** Sets the declared value of the goods, used on quotes and Bills of Lading when the items have no value recorded. Declared value affects the carrier's liability if your freight is damaged or lost, and can affect the price. **When you'd set it:** If you ship goods of broadly similar value and your item records don't carry values. ### Default Load Notes **What it does:** Places text in the notes on every new quote or load. **When you'd set it:** Only for instructions that apply to *everything* you ship, like "Call 30 minutes before arrival". **When to leave it empty:** Anything shipment-specific will appear on all the shipments it doesn't apply to, and notes that are usually irrelevant get ignored — including the times they matter. ### Freight Class **What it does:** Sets the LTL freight class — the standard category between 50 and 500 that largely determines what an LTL shipment costs. Owlery usually works it out from weight and dimensions; this setting covers the cases where it can't. **When you'd turn on the override:** Turn on **Will override computed values** only if you have a class agreed with your carrier — for example a negotiated FAK ("freight all kinds") arrangement where everything is billed at one class. With the override on, your chosen class is used even when Owlery could have calculated one. Without an agreed class, you'll quote at a class the carrier corrects later, and the correction arrives as a re-class charge. ### Pre-2025 Freight Class Rules **Value:** On / Off **What it does:** Keeps calculating with the freight classification rules that applied before 2025. The national rules changed that year, including how density-based sub-classes work. **When you'd turn it on:** If you have carrier contracts or customer agreements written against the old rules. **When to leave it off:** Everywhere else — off is the current standard. ## Carrier Quoting ### Preferred Brokers **What it does:** Sets which of your connected carriers and brokers are ticked by default when someone opens a quote. **When you'd set it:** Put your primary partners here so your team gets the rates that matter without ticking boxes each time. They can still add or remove carriers on an individual quote. ### Additional Rates **Value:** On / Off **What it does:** Also asks for rates from brokers you don't have an account with, so you see market pricing alongside your contracted rates. **When you'd turn it on:** To check your negotiated rates are still competitive, or when your usual partners can't cover a lane. ### Competitive Bid Carrier Visibility **Value:** On / Off **What it does:** Tells a carrier that has submitted a quote that a materially lower bid exists — but not who, or how much. **When you'd turn it on:** Carriers who know they're beaten sometimes come back with a better number. **When to leave it off:** If your carrier relationships are contracted rather than competitive. ### Carrier SCAC Blacklist **What it does:** Excludes carriers from quoting entirely, identified by SCAC. **When you'd set it:** After a service failure or a decision not to work with a carrier, so nobody on your team accidentally books them again. ### Weight/Quantity Threshold **What it does:** Sets the size at which a shipment stops being LTL and starts being FTL, so quotes offer the right mode options. A shipment above **either** FTL minimum (weight or quantity) triggers a full-truckload quote; it must be under **both** LTL maximums to get an LTL quote. **When you'd set it:** When your team is getting quote options that don't fit how you ship — LTL rates on shipments that really need a truck, or the reverse. These settings appear only when the feature is active on your account. ## Quote Form Fields ### Stop Requirements **What it does:** Sets the accessorial services ticked by default for a stop — liftgate, inside delivery, appointment, or limited-access location. There's one setting for pickups and one for dropoffs. **When you'd set it:** Where a requirement is true almost every time, for example if all your deliveries are residential and need a liftgate. Your team can still change it on an individual quote. Carriers need to know about these up front. Requesting a liftgate after the truck arrives without one is a failed delivery and a redelivery charge. ### Pickup Date Fallback **What it does:** Sets the window Owlery assumes when a quote arrives with no pickup date — a range of days from today, for example 1 to 3 days out. **When you'd set it:** Rates vary with date, so this keeps pricing realistic on quotes that reach you without dates. ### Allow Same-Day Pickup **Value:** On / Off **What it does:** When **On**, an order asking for pickup today keeps today's date. When **Off**, a pickup date of today or earlier moves to tomorrow. **When you'd turn it on:** Only if your dock and your carriers can act on a request made this morning. **When to leave it off:** Otherwise — leaving it off keeps quotes honest. ### Dropoff Date Fallback **What it does:** Sets the window Owlery works backwards over to set a pickup date, for when you know when goods have to *arrive* but not when they need to leave. **When you'd set it:** Set the range wide enough to cover realistic transit time. ### Remove Dimension Field **Value:** On / Off **What it does:** Hides the dimension fields on the quote page. **When you'd turn it on:** Only if dimensions always arrive automatically from your item data. **When to leave it off:** If your team enters dimensions by hand — hiding the field means quoting without them, which usually means worse pricing. ### Remove Date Field **Value:** On / Off **What it does:** Hides the pickup and dropoff date fields on the quote page. **When you'd turn it on:** If your team quotes for indicative pricing and real dates get set later. Pair it with the two date fallbacks above so Owlery still has something sensible to price against. ### Appointment Time Increment **What it does:** Sets how the appointment time menu is divided — every 15 minutes, every 30, every hour. **When you'd set it:** Match it to how your facilities book docks. Your team can always type an exact time regardless. ## Quote Date Warnings **Value:** On / Off **What it does:** Warns you when a carrier's estimated pickup or delivery date falls outside the dates you asked for. **When you'd turn it on:** Worth turning on generally — carriers routinely return a quote that's cheap but slower than you need, and the date difference is easy to miss. For how the comparison works, see [Quote Response Date Warnings](/shippers/quote-response-date-warnings). ## Dock Scheduling ### Show Same Order Appointment Action **Value:** On / Off **What it does:** Adds a **Same Order** action, which creates another dock appointment against an order that already has one, carrying the details over. **When you'd turn it on:** If orders regularly need more than one appointment — split shipments, partial pickups, or multiple trucks over several days. This setting appears only when Dock Scheduling is active on your account. ## API ### Skip External Quote Deduplication **Value:** On / Off **What it does:** Disables the check that normally stops a quote request sent twice through the external quoting API from creating a second quote. **When you'd turn it on:** Only if many of your orders genuinely look identical — same lane, weight, and dates — and the duplicate check is rejecting real, separate shipments. **When to leave it off:** Otherwise. It's what stops a retried API call from cluttering your quote list. # Connect Ramp to Owlery Source: https://help.owlery.ai/shippers/ramp Set up a Ramp developer app and link it to Owlery so invoice and bill data syncs automatically. Connecting Ramp lets Owlery read and write bill data, pull vendor records, and sync accounting info from your Ramp account. The setup takes about 10 minutes and has two parts: create an app in Ramp, then link it in Owlery. You'll need **admin access in Ramp** to create a developer app. If you don't see the Developer section in Ramp, ask your Ramp admin to set this up or grant you access. Ramp also provides an official [guide to building OAuth apps](https://docs.ramp.com/developer-api/v1/guides/building-oauth-apps). Use the steps below for Owlery's required settings and values. ## Part 1 — Create your app in Ramp In Ramp, scroll down in the left-hand navigation to **Company** and select **Developer**. On the **Apps** tab, click **Create new app**. Image Enter `Owlery` as the **App name**, accept Ramp's Developer Terms of Service, and click **Create app**. Image ## Part 2 — Configure the app Once the app is created, you'll land on its settings page. Work through each section below. ### Redirect URI Under **Redirect URIs**, click **+ Add new URI** and add this URL: ```text theme={null} https://owlery.ai/api/auth/integrations/callback/ramp ``` This tells Ramp where to send you after you authorize the connection. ### Grant types Under **Grant types**, enable all three toggles: * **Authorization code** * **Client credentials** * **Refresh token** All three need to be on for the connection to work. Image ### Scopes Scroll to **Scopes** and click **Configure allowed scopes**. Add each of the following: | Scope | What it does | | ----------------- | ----------------------------------- | | `bills:write` | Lets Owlery create and update bills | | `bills:read` | Lets Owlery read bill data | | `vendors:read` | Lets Owlery read vendor records | | `entities:read` | Lets Owlery read entity data | | `accounting:read` | Lets Owlery read accounting data | ### Save your credentials After saving the app, Ramp displays a **Client ID** and **Client Secret**. Copy both — you'll need them in the next step. The Client Secret is only shown once. If you lose it, you'll need to generate a new one in Ramp. ## Part 3 — Connect in Owlery In Owlery, go to add an integration. In the search box, type `ramp` and select **Ramp**. Image Paste the values from Ramp: * **Client ID**: from your Ramp app * **Client Secret**: from your Ramp app * **API URL**: enter `https://api.ramp.com` Click **Continue**. You'll be redirected to Ramp to approve Owlery's access. Once you approve, Ramp sends you back to Owlery and the connection is live. ## Troubleshooting The Developer section is only visible to Ramp admins. Ask your Ramp admin to either create the app for you or grant you admin access. Double-check that the redirect URI in your Ramp app matches exactly: `https://owlery.ai/api/auth/integrations/callback/ramp`. Extra spaces or a missing trailing path segment will break the redirect. Make sure all five scopes are enabled on your Ramp app. If you added scopes after the initial authorization, you may need to disconnect and reconnect in Owlery to pick up the new permissions. # How Ramp + NetSuite Payments Work Source: https://help.owlery.ai/shippers/ramp-netsuite-payments The end-to-end path an approved Owlery invoice takes to become a paid Vendor Bill in NetSuite — using Ramp for bill pay. 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 ```mermaid theme={null} flowchart LR classDef owlery fill:#166E3F,stroke:#0f4f2d,color:#ffffff,font-weight:bold; classDef ramp fill:#F3E8FF,stroke:#7C3AED,color:#3b1a63; classDef netsuite fill:#E8F1FF,stroke:#2563EB,color:#0b2e6b; subgraph OWL[" Owlery "] direction TB A[Approved
Owlery invoice] PAID[Invoice
marked paid] end subgraph RMP[" Ramp "] direction TB D[Draft Bill
draft_bill_id] B[Bill
bill_id] PAY[Payment details
nested on Bill] end subgraph NS[" NetSuite "] direction TB VB[Vendor Bill] VP[Vendor Payment /
Bill Payment] end A -- "Owlery creates
POST /bills/drafts" --> D D -- "Approved in Ramp" --> B B -- "Ramp processes payment" --> PAY B -. "Phase 1: BILL_SYNC" .-> VB PAY -. "Phase 2: BILL_PAYMENT_SYNC" .-> VP VP -. "Applied against" .-> VB PAY -. "bill.paid webhook" .-> PAID class A,PAID owlery; class D,B,PAY ramp; class VB,VP netsuite; ``` **Who does what.** Solid arrows are actions **Owlery** performs (creating the draft bill) or a person performs in Ramp (approving, paying). Dotted arrows into NetSuite are performed by **Ramp's own native NetSuite accounting sync** — Owlery does not write the Vendor Bill or payment 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 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. 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. After approval, Ramp processes the payment (ACH, card, check, etc.). The payment details are attached to the bill in Ramp. 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. 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 | Question | Where to look | | ----------------------------- | ------------------------------------------------------------------- | | Did the bill reach Ramp? | Ramp → Bills. It appears as a draft/awaiting-approval bill. | | Has it been paid? | Ramp bill status, and the Owlery invoice flips to **Paid**. | | Is it in the books? | NetSuite → the Vendor Bill, with a Bill Payment applied against it. | | Which carrier / load is this? | The bill memo shows the Owlery invoice and load number(s). | **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 | Boundary | Owner | Mechanism | | ------------------------------------ | ------------------------- | ---------------------------------------------------------- | | Owlery invoice → Ramp draft bill | **Owlery** | Ramp Developer API (`POST /developer/v1/bills/drafts`) | | Draft bill → approved bill | **Ramp** (human approval) | Ramp app | | Payment execution | **Ramp** | Ramp bill pay | | Ramp bill → NetSuite Vendor Bill | **Ramp** | Ramp native NetSuite accounting sync (`BILL_SYNC`) | | Ramp payment → NetSuite Bill Payment | **Ramp** | Ramp native NetSuite accounting sync (`BILL_PAYMENT_SYNC`) | | Paid status → Owlery invoice | **Ramp → Owlery** | Ramp `bill.paid` webhook | 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 ```mermaid theme={null} sequenceDiagram autonumber participant O as Owlery participant R as Ramp API participant AP as AP approver participant N as NetSuite O->>R: POST /developer/v1/bills/drafts
(vendor_id, invoice_number, line_items,
issued_at, due_at, remote_id = invoice.id) R-->>O: RampDraftBill { id, status, deep_link_url } Note over O: Persist accountingSyncs[] on invoice
{ integrationAuthId, source: Ramp,
sourceId = draft_bill_id, status, syncedAt } AP->>R: Approve bill in Ramp R-->>N: Phase 1 BILL_SYNC → create Vendor Bill AP->>R: Pay bill (ACH / card / check) R-->>N: Phase 2 BILL_PAYMENT_SYNC → Bill Payment,
applied against Vendor Bill R-->>O: bill.paid webhook (keyed on integrationAuthId + sourceId) Note over O: Set accountingSyncs.paidAt →
invoice marked paid ``` ## 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 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](/shippers/ramp). 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. 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 | Symptom | Likely cause | | ----------------------------------------------- | ---------------------------------------------------------------------------------- | | Draft bill never appears in Ramp | Missing/incorrect Broker → Ramp Vendor mapping, or missing `bills:write` scope. | | Bill in Ramp but not in NetSuite | Ramp `BILL_SYNC` not enabled, or vendor/subsidiary/GL mapping missing **in Ramp**. | | Vendor Bill exists but no payment recorded | Ramp `BILL_PAYMENT_SYNC` not enabled, or payment account unmapped in Ramp. | | Bill paid in Ramp but Owlery invoice still open | `bill.paid` webhook not delivered/subscribed. | # Review Responses & Tender Source: https://help.owlery.ai/shippers/review-responses-and-tender A walkthrough of the quote drawer's Details tab — comparing carrier rates, picking a winner, sending rate cons and BOLs, and booking the load. **Where to find it:** `Quotes → click any quote row → Details tab` Once carrier responses start coming in, the **Details** tab of the quote drawer is where the decision happens: compare rates side by side, pick your carrier, and turn the quote into a booked load. ## Comparing carrier responses Every carrier you sent the request to gets a row in the **Details** tab. A few things to check before you commit: * **Is the rate competitive?** Flip to the **Lane History** tab for a historical rate chart on this exact origin–destination pair. * **Is the quote still valid?** Carrier quotes carry an expiration date — an expired bid needs to be refreshed before you can tender against it. You can always **Re-quote** to send a fresh round of requests. * **Are responses still arriving?** A spinning **Quoting…** indicator means carriers are still bidding; there's no harm in waiting for the field to fill in. ## Selecting a carrier When you've found your winner, select that carrier's response. Depending on your workspace setup, this happens in one or two steps: * **One-step tendering**: selecting the response tenders the load to that carrier immediately. The quote moves to **Tendered**. * **Two-step tendering**: selecting the carrier first moves the quote to **Carrier Selected**, and you send the tender as a separate action. This gives you a checkpoint to finalize details before the carrier is committed. Once the tender goes out, the carrier reviews it on their side and clicks **Accept** or **Reject**. When they accept, the quote status moves to **Accepted**. ## Tendering and booking the load Once the carrier accepts, the shipment becomes a load you can track end to end: * Track the tender's full lifecycle — including cancellations and re-tenders — in the drawer's **Tender History** tab, which also shows the load status once a load exists. * Jump to the load, related orders, and any other connected records from the **Linked Items** tab. * Manage the shipment itself — live tracking, status updates, and documents like PODs — from the **Loads** page. Need to unwind a tender? Cancel it and the quote moves to **Cancelled**; you can then tender to a different carrier or **Re-quote** to start a fresh round. The full trail stays visible in **Tender History**. ## Handy to know * **You can show carriers competitive pressure** (controlled via your Shipper Settings) - other bids come in significantly lower, high bidders may get an alert prompting them to revise. It can pay to leave a quote open a little longer before tendering. * **The tendered price shows in the table** - once you tender, the accepted response's price appears in the **Tendered At** column on the Quotes page. * **Expired doesn't mean dead** - carriers can resubmit on an open request after their quote expires, and you can always re-quote to restart bidding. # Adding Lanes to Your RFP Source: https://help.owlery.ai/shippers/rfps/adding-lanes Three ways to get lanes into your RFP: upload a file, use Owlery's suggestions, or type them in. **Where to find it:** `Dashboard → RFPs → Create RFP` Lanes are the shipping routes you want carriers to bid on. The Create RFP page gives you three tabs for adding them, and you can use all three in the same RFP — start with a batch of suggestions, then hand-add the two new lanes that aren't in your history yet. | Tab | Best for | How many at a time | | ----------------------- | ---------------------------------------------------------- | ------------------------------------------ | | **Upload Lanes** | Large bids, and anything you already keep in a spreadsheet | Hundreds | | **Suggest Lanes To Me** | Re-bidding lanes you already run | As many as your contracts and history hold | | **Enter Lanes Myself** | New business, one-offs, or filling a gap in a list | One | Switching tabs never removes lanes you've already added. Every lane needs at least two stops, whichever tab you used. ## Upload a CSV File Start with **Download CSV Template** instead of building your own headers. The template comes out already matching your account's units (miles or kilometres, lbs or kgs). Before it downloads, you'll answer three questions: * **Max # of stops**: how many stops your longest lane has. A 2-stop template is much easier to read than a 5-stop one, so don't go higher than you need. * **Location detail**: **Full Address**, **City/State/Zip**, or **Zip Only**. Pick the least detail that still identifies the lane. * **Prefill with contract rates**: fills the file with the lanes on your current contracts, including their rates, so you can re-bid your book by editing a file instead of typing it. Then fill it in and upload it. A few things to know: * **One row is one lane**: a file can mix 2-stop and 3-stop lanes, since Owlery reads the stop count from the columns you filled in. * **Zip code is the only stop detail you have to provide**, plus city and state on the full-address and city/state/zip templates. If you filled in a facility's lookup code, you can leave that stop's address columns blank. * **Everything else is optional**: equipment type (dry van unless you say otherwise), distances, volume, weight, and target rate. * **Distances are worth filling in**: they're what let you see a rate per mile and apply per-mile fuel surcharges. * **Volume is all or nothing**: if you give a minimum, give a maximum too. If any row in the file has a problem, nothing is imported. Owlery tells you which rows to fix — correct the file and upload it again. Uploading a second file, or removing the file, deletes the lanes that came from the first one. Owlery asks you to confirm first. Lanes you added by hand or from suggestions aren't touched. ### Equipment and Driver Options Once your lanes are in the table, a strip above it lets you tick **Shipment Mode** (Truck or Rail) and **Driver Mode** (Solo or Team). These add lanes rather than filter them. Every combination you tick creates its own copy of every row in your file, so carriers bid on each one separately. Tick Solo and Team on a 24-row file and you get 48 lanes. Owlery shows you the count as you go. The default is Truck plus Solo, which is one lane per row. ## Let Owlery Suggest Lanes This tab builds a lane list out of what Owlery already knows about your freight, so you can re-bid your network without assembling a file. Suggestions come from two places: * **Your contracts**: lanes you already have rates on file for. The contract rate carries over as the starting target rate, and the lane shows a handshake icon. * **Your load history**: lanes you actually moved, grouped together. These show a sparkle icon. Set the filters, then press **Filter**. The list only refreshes when you press it. * **Include existing contracts**: on by default. Turn it off to bid only lanes you've physically run. * **Use historical lanes from the last...**: on by default at 6 months. Turn it off to work only from contracts. * **With at least N loads**: drops lanes that ran fewer than that many times. This is the main dial for keeping one-off spot moves out of a contract bid — raising it to 5 or 10 leaves you with lanes that have real, repeatable volume. Changing a filter clears whatever you had selected, so you can't accidentally add lanes from an old list. A few things Owlery does for you: it groups matching loads into one lane even when the same address was typed three different ways, it shows the contract version when a lane is both contracted and in your history, and it estimates a weekly volume range from how often the lane ran. Volume, weight, target rate, and rate per mile are all editable right in the suggestion table before you add anything. Editing a suggestion doesn't change the underlying contract or your load history. **Nothing suggested?** Your filters are probably too tight — widen the lookback window or lower the minimum load count. If you have no contracts and no recent loads on file yet, upload a CSV file or enter lanes by hand this time. Once you award this RFP, those lanes become suggestions for your next one. ### Options Multiply Your Selection Above the suggestion table, **Shipment Mode**, **Equipment**, and **Truck Driver Mode** set which versions of each lane carriers should bid on. Each lane you select is added once per combination, and the button tells you the total before you commit — 12 lanes bid for both dry van and reefer becomes **Add 24 Lanes**. Pick at least one shipment mode and one equipment type, or nothing can be selected. ## Enter Lanes by Hand A simple form, one lane at a time: pick equipment, solo or team, truck or rail, then add your stops. Stops autocomplete against your saved facilities, and you can add as many as the lane needs. Per stop, you can record transit time and the distance to the next stop. Then set the lane's volume range, total weight, and a target rate — enter it as a total or per mile and Owlery works out the other one, as long as the lane has all its distances. **Add Lane** drops it into the table and keeps your settings for the next one, including the first stop. That makes a run of lanes out of the same origin quick to enter. ## Next Step Once your lanes, carriers, and dates are set, send the RFP and start comparing bids. # RFP Overview Source: https://help.owlery.ai/shippers/rfps/overview What an RFP is, what you need before you start, and how to build and send one. An RFP is how you ask your carriers to bid on a set of lanes all at once, then turn the bids you accept into contract rates. **Where to find it:** `Dashboard → RFPs → Create RFP` ## How It Works You build a list of lanes, choose which carriers get to bid, and set a deadline. Owlery emails each carrier their lanes, and their bids come back into Owlery so you can compare them side by side. When you award a bid, it becomes a contract rate you can quote and tender against. RFP is an add-on feature. If it isn't on your plan, the Create RFP page shows an upgrade message instead of the builder. ## Before You Start * **Add your carriers first**: only carriers already in Owlery show up in the carrier list. See [Who Can Bid](#who-can-bid) below for the two ways to add one. * **Carriers don't need an integration**: a carrier you only have an email contact for can still bid. * **Set lookup codes on your facilities**: then you can list a stop by its code instead of typing the full address. See [Facility Profile](/facilities/facility-profile). ## How to Build and Send One Everything happens on one page. Fill in the top, add your lanes, then set carriers and dates at the bottom. The name is filled in with the current month, like "RFP September 2026". Your carriers see this name, so make it something they'll recognize. Use the optional **Description** for anything carriers should read before they bid — service expectations, seasonality, or when you plan to award. **Attach Documents** at the top right shares files with every carrier you invite — a bid packet, insurance requirements, or accessorial rules. You can upload a CSV file, let Owlery suggest lanes you already run, or type them in one at a time. See [Adding Lanes to Your RFP](/shippers/rfps/adding-lanes). Every lane you add appears in the table, with its stops, equipment, volume, weight, distance, and target rate. Whatever is in this table is what gets sent, so give it a read before you send. To remove one lane, use the menu on its row. To start over, use **Clear All** in the toolbar menu. Pick one or more carriers under **Include the following carriers for proposal**. Every carrier you pick is asked to bid on every lane in the RFP. * **Contract Starts** and **Contract Expires**: the period the rates you award will cover. * **Deadline to Submit Bids**: the date and time bids are due. You can extend this later. Owlery emails each carrier the lanes you asked them to bid on, and takes you to the RFP's lane list. See [Running Your RFP](/shippers/rfps/running). Your carrier list is locked once you send. A carrier you add to Owlery afterward can't join an RFP that's already out, so get your list right before you send. ## Who Can Bid Every carrier you have a relationship with in Owlery can be invited, even one you've never tendered a load to. To invite a carrier who isn't in Owlery yet, add them as a contact at [owlery.ai/dashboard/contacts](https://owlery.ai/dashboard/contacts) before you build the RFP. Enter their email and Owlery fills in their name and carrier for you. Give them the **RFP Manager** role, which sends them RFP requests without subscribing them to day-to-day quote, tender, and load email. This is the right route for a carrier you only want bids from. If you also plan to quote and tender with them, set them up as a full integration instead — see [Add a Carrier or Broker](/shippers/carrier-portal/add-a-carrier-or-broker). ## Good to Know * **Your draft is saved on your computer**: lanes stay in the table if you leave the page and come back on the same computer. A teammate on a different computer won't see your draft. * **An RFP with no lanes is a draft**: you can reopen it and finish it in the builder later. Once an RFP has been sent, you can't edit it back through the Create RFP page. ## Next Steps Three ways to get lanes into your RFP: upload a CSV file, use Owlery's suggestions, or type them in. Compare bids, run another round, extend a deadline, and award your lanes. # Running Your RFP Source: https://help.owlery.ai/shippers/rfps/running Compare bids, run another round, extend a deadline, and award lanes to your carriers. **Where to find it:** `Dashboard → RFPs` Once you send an RFP, round 1 opens and every carrier you invited can bid on every lane. Bids land in Owlery as carriers respond, and you work through them lane by lane until each one is awarded. ## Reading the Bids on a Lane Open your RFP to see its lane list, then open a lane to see its **Current Round** table — one row per carrier, showing the bid, the rate per mile, who submitted it, and when. Bids that meet your target rate are flagged for you. The **All Rounds** tab shows one column per round, newest first, so you can see how each carrier moved between rounds and which round a bid was awarded in. ## Rounds Happen Per Lane The round number in the lane list belongs to that lane, not to the whole RFP. One lane can be awarded in round 1 while another is still going in round 3, and that's normal — you're negotiating each lane on its own. ## Your Three Options ### Extend the Deadline Use this when you just need more time, not another pass at pricing. From the lane list, select the lanes you want and extend the submission deadline on all of them at once. The carriers on those rounds are emailed the new date. ### Start a New Round Use this when you want a shortlist to sharpen their bids. In a lane's Current Round table, choose **New Round**, pick the bids you want to keep, and set a new deadline. Those carriers move into the next round and are notified. The previous round closes, so no one can revise a bid in a round you've moved past. Only carriers who submitted in the round can be moved into the next one. ### Award the Lane Use this when a bid is where you want it. **Award** accepts one or more bids on the lane. You can award more than one carrier — handy for primary and backup coverage — and you can award some lanes while others keep bidding. Awarding ends the negotiation on that lane, so **New Round** is no longer offered for it. ## Another Round or Award? **Run another round** when the spread between bids is wide, when you want your shortlist competing against each other, or when a carrier you like came in above target. **Award** when a bid is where you want it. There's no prize for extra rounds — carriers get bid fatigue, and a good rate is a good rate. ## What Happens After You Award Awarded bids become contract rates on your `Dashboard → Contracts` page, ready to quote and tender against. They also become suggestions the next time you build an RFP. See how awarded rates are stored, edited, and used to price your loads. # SAP Business One Integration Source: https://help.owlery.ai/shippers/sap-business-one Owlery designs the order-selection and mapping rules around your Service Layer data. Owlery connects to SAP Business One through the Service Layer API. We synchronize sales and purchase orders, resolve partners and warehouses, and enrich shipments with references from linked delivery notes. SAP Business One deployments differ in hosting, network access, certificates, and custom fields. Owlery confirms technical availability and the Service Layer endpoint during implementation. This is not a generic self-service setup. **Where to find it:** `Settings → Integrations` ## Two parts of the integration Synchronize sales and purchase orders and enrich linked shipments from delivery notes. Review order scope, OData filters, customer codes, parcel carrier codes, and exact lookup. The current SAP Business One connector is inbound-only. Owlery documents any requested outbound workflow separately before proposing an extension. ## Getting started Provide the company database, username, password, and network access for the approved Service Layer endpoint. Owlery confirms reachability and permissions. Share representative sales orders, purchase orders, and delivery notes. Owlery learns your customer codes, warehouses, carrier values, and shipment-reference patterns from the data. Owlery presents the recommended order scope, OData filters, mappings, and parcel rules. Your team confirms the intended business outcome. Owlery validates normal and delivery-note enrichment scenarios, starts synchronization, and monitors the first records. Need help planning your SAP Business One connection? Email [support@owlery.ai](mailto:support@owlery.ai). # SAP Business One Configuration Reference Source: https://help.owlery.ai/shippers/sap-business-one/configuration Order scope, OData selection, customer filtering, and parcel classification. Owlery studies your SAP Business One documents and recommends the Service Layer filters and mappings required by your freight workflow. You do not need to write OData filters yourself. Owlery creates and maintains the approved configuration. | Area | Available controls | | ------------------------- | ------------------------------------------------------------------------ | | Order types | Synchronize sales orders, purchase orders, or both | | Incremental sync | Retrieve records changed after the prior successful synchronization | | Customer scope | Exclude specified `CardCode` values or synchronize only an approved list | | Per-type query rules | Apply a separate Service Layer OData filter to sales or purchases | | Default query rule | Apply a fallback OData filter when no type-specific rule exists | | Parcel classification | Treat configured order or delivery-note carrier codes as parcel | | Exact lookup | Retrieve a sales or purchase order by document number | | Shipment-reference lookup | Find a linked order using delivery tracking or bill of lading | | Full synchronization | Run a complete order backfill or reconciliation | ## Authentication details Owlery needs the company database, Service Layer username, and password. The approved user needs read access to the selected sales orders, purchase orders, delivery notes, business partners, and warehouses. Service Layer hosting, network access, certificates, and custom fields vary. Owlery confirms endpoint reachability and the exact permissions during implementation. ## Read-only boundary The current SAP Business One connector is inbound-only. If your workflow requires outbound updates, Owlery documents the target SAP record, event, field, permissions, and API extension before proposing that work. # Reading Data from SAP Business One Source: https://help.owlery.ai/shippers/sap-business-one/reading-data How Owlery synchronizes orders and enriches sales shipments from delivery notes. Owlery retrieves SAP Business One orders through the Service Layer, follows related partners and warehouses, and converts the results into Owlery freight orders. ## Synchronized records | SAP Business One record | How Owlery uses it | | ----------------------- | ---------------------------------------------------------------------------------------------------- | | Sales Order | Customer shipment with warehouse pickup, customer delivery, dates, items, and references | | Purchase Order | Supplier-associated shipment with the SAP ship-to destination, supplier profile, due date, and items | | Delivery Note | Enriches a linked sales order with tracking, bill of lading, and carrier information | Mapped data can include document numbers and identities, open or closed status, timestamps, customer or supplier details, warehouses, addresses, dates, item codes, descriptions, quantities, line numbers, prices, totals, units, notes, purchase-order references, bill of lading, tracking, PRO, and carrier values. ## Delivery-note enrichment SAP Business One may add shipment information to a Delivery Note without updating the source Sales Order. Owlery handles both paths: * During sales-order processing, Owlery queries linked delivery lines and applies available references. * After the main incremental sync, Owlery scans recently changed delivery notes and refreshes affected sales orders. Large lookups are chunked to stay within Service Layer URL limits. Explicit page sizes prevent matching delivery records from being omitted by default API limits. ## Synchronization and reliability * **Pagination** processes large order sets in bounded pages. * **Incremental watermarks** order changed transactions by SAP update date. * **Delivery lookback** includes a buffer around date-only delivery updates. * **Reference caching** avoids repeatedly requesting the same partner or warehouse. * **Targeted retries** retry selected supporting-record lookups after temporary failures. * **Chunked enrichment** keeps delivery and order lookups within request limits. * **Exact refresh** retrieves the current source record for reconciliation. * **Shipment-reference lookup** can find a linked sales order by delivery tracking or bill of lading. The current connector reads SAP Business One data into Owlery. It does not write fulfillment, receipt, quote, or shipment updates back. # SAP S/4HANA Integration Source: https://help.owlery.ai/shippers/sap-s4hana Owlery follows your SAP document flow and designs the matching freight workflow. Owlery connects to SAP S/4HANA through OData services. We synchronize sales, purchasing, delivery, and stock-transfer data, preserve relationships across SAP documents, and configure selected tender-result write-back when supported by your deployment. SAP services, partner functions, text types, pricing conditions, and permissions vary by implementation. Owlery discovers the available document flow and recommends the smallest configuration that fits your process. **Where to find it:** `Settings → Integrations` ## Three parts of the integration Synchronize sales, deliveries, requisitions, purchase orders, and stock transfers. Optionally return carrier, quote-number, and allocated freight results through approved SAP services. Review grouping, requisition-origin, record-family, lookup, and write-back controls. ## Getting started Provide a dedicated API user, endpoint, and permissions for the OData services in the approved workflow. Owlery confirms the inbound and any approved outbound services. Share representative sales orders, deliveries, requisitions, purchase orders, or stock transfers. Owlery follows the relationships and learns the plants, partners, items, and pricing conventions. Owlery presents the recommended document scope, grouping, mappings, and optional write-back. Your team confirms the operational and write-back behavior. Owlery tests normal and exception scenarios, enables the agreed configuration, and monitors the first records. Need help planning your SAP S/4HANA connection? Email [support@owlery.ai](mailto:support@owlery.ai). # SAP S/4HANA Configuration Reference Source: https://help.owlery.ai/shippers/sap-s4hana/configuration Document scope, order grouping, requisition origins, lookup, and write-back controls. Owlery reviews your SAP document flow and recommends the grouping, filters, mappings, and optional write-back supported by your services. | Area | Available controls | | ------------------------ | -------------------------------------------------------------------------------- | | Sales grouping | Group by production plant or individual sales-order item | | Requisition origin | Include all origins or selected SAP origin values | | Record families | Enable or disable sales, purchase, and transfer synchronization | | Purchase versus transfer | Treat purchase order type `UB` as a stock transfer | | Full or incremental sync | Run a backfill or retrieve changed records | | Exact lookup | Retrieve a sales, requisition, purchase, or transfer document and optional item | | Quote write-back | Enable selected carrier, quote-number, and quote-amount actions | | Write-back scope | Enable each outbound action independently | | Freight allocation | Allocate one tender across orders and SAP items while preserving the exact total | | Additional freight rules | Apply an approved separate freight-charge condition when required | ## Sales order grouping | Grouping | Owlery identity | Best fit | | ---------------- | ------------------------------- | ------------------------------------------------ | | Production plant | `{SalesOrder}-{Plant}` | Lines from one production plant move together | | Sales-order item | `{SalesOrder}-{SalesOrderItem}` | Each line needs independent planning or tracking | Plant grouping is the default. Owlery recommends the grouping that matches how your team tenders freight. ## Requisition origins The origin filter can distinguish requisitions created by MRP, direct procurement, production, store orders, manual entry, planned-order conversion, sales documents, planning systems, projects, external requirements, or self-service procurement. Leave the filter empty to include every origin. ## Authentication details Owlery needs the approved SAP API endpoint plus a dedicated username and password. Permissions depend on the selected inbound and outbound OData services. Some deployments use custom services for purchase-order partners, texts, or pricing. Owlery confirms the exact service names, partner functions, text types, pricing conditions, and permissions during discovery. # Reading Data from SAP S/4HANA Source: https://help.owlery.ai/shippers/sap-s4hana/reading-data How Owlery follows SAP sales, delivery, purchasing, and stock-transfer document flows. Owlery follows relationships across SAP S/4HANA documents so operational shipments remain aligned with the underlying sales, delivery, and purchasing flow. ## Synchronized records | SAP record | How Owlery uses it | | ----------------------------- | ------------------------------------------------------------------------------ | | Sales Order | Customer shipments grouped by production plant or sales-order item | | Outbound Delivery | Shipped quantities, bill of lading, and pickup dates for linked sales orders | | Purchase Requisition | Purchasing shipment for each requisition item with available sales assignments | | Purchase Order | Supplier shipment for each purchase-order item | | Stock Transfer Purchase Order | Internal transfer between supplying and receiving plants | Depending on the document family, Owlery can map document and item identities, timestamps, statuses, materials, quantities, units, weights, prices, plants, partners, facilities, dates, references, item text, pricing conditions, and currency. ## Document relationships Owlery preserves links between purchase requisitions and purchase orders in both directions. Account assignments can identify a related sales order and customer delivery address. This supports drop-ship and make-to-order flows without duplicating document relationships outside SAP. For outbound delivery batch splits, Owlery can use child delivery lines when they represent the actual shipped quantities. ## Operational mapping * Sales facilities come from production plants and ship-to partners. * Purchasing facilities come from suppliers and linked customer addresses. * Stock transfers use supplying and receiving plants. * Requested, delivery, loading, and linked-sales dates are mapped when available. * Material lines retain SAP item identities, quantities, prices, weights, volumes, and units. * Bill of lading values remain tied to the relevant item or plant group. ## Synchronization and reliability * **Incremental synchronization** uses SAP change timestamps and bounded lookbacks. * **Requisition fallback** uses creation time when an item lacks a change timestamp. * **Delivery re-enrichment** scans changed delivery items when SAP does not update the sales header. * **Pagination** drains each enabled record family independently. * **Chunked lookups** retrieve related sales orders within practical OData request sizes. * **Relationship caching** avoids repeated partner and plant address calls. * **Exact lookup** retrieves a specific document and optional item for reconciliation. # Writing Back to SAP S/4HANA Source: https://help.owlery.ai/shippers/sap-s4hana/writing-back How Owlery returns selected carrier, quote-number, and freight results to approved SAP services. SAP S/4HANA write-back is optional and deployment-specific. Owlery studies the available partner, text, and pricing services, recommends the supported actions, and enables only the approved workflow. Your team confirms the intended SAP outcome. Owlery configures the strategies, validates source documents and item identities, and monitors the writes. ## Available tender-result actions | Owlery result | SAP action | | ----------------------------------------- | ---------------------------------------------------------- | | Carrier selected for a sales order | Validate SCAC and update the item-level ship-via partner | | Carrier selected for purchase or transfer | Validate SCAC and create or update the approved PO partner | | Quote selected for a sales order | Write the Owlery quote number to sales-order item text | | Quote selected for purchase or transfer | Create or update approved purchase-order item text | | Freight selected for a sales order | Create or replace the approved item pricing condition | | Freight selected for purchase or transfer | Create or update the approved PO item pricing condition | ## Exact freight allocation One tender can cover multiple SAP-derived shipments. Owlery first allocates the quote across Owlery orders, then across SAP items using available weights. Residual-aware rounding ensures the values written across every item equal the selected tender amount exactly. ## Validation before writing Owlery validates: * Document-number formats * Supported order types * Source item identities * Quote availability * Item weights when allocation requires them * Carrier codes when a SCAC is recorded * Availability and permissions of the approved SAP service ## Safe writes by design * Each carrier, quote-number, and quote-amount action is independently enabled. * Source records and item identities are loaded before updates. * Multi-order and multi-item allocations must reconcile exactly. * Validation errors stop the affected action instead of being blindly retried. * The exact partner, text, and pricing services are documented for the deployment. # Shipper Settings Overview Source: https://help.owlery.ai/shippers/shipper-settings The defaults Owlery applies as shipments move from order to invoice. Set them once. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings` Shipper Settings is where your organization sets its house rules — the defaults Owlery applies automatically as a shipment moves from order to quote to tender to load to invoice. Set them once and your team stops re-typing the same values on every shipment. Settings apply to your whole organization, not just to you. Changing one changes it for all of your teammates. ## How the Page Works The page opens as a set of cards, one per topic. Click a card to open that topic and see its settings, then use the breadcrumb at the top to come back. Every setting shows its name, a short description, and its current value. A value of `--` means the setting has never been set, so Owlery falls back to its built-in behavior. * **On/off settings**: flip the switch right in the row. It saves immediately. * **Everything else**: click the edit action in the row (**Update**, **Manage**, or **Add Contact**), fill in the small form that opens, and save. Some settings only appear once the matching feature is turned on for your account. Where that applies, you'll see an unlock prompt instead of the settings. ## Where to Start * **Contacts**: set your Logistics Contact first. It's the fallback used across quoting, logistics, and writeback. * **Quoting**: pallet dimensions, weights, and freight class prefill your quote forms automatically. Filling these in is the single biggest way to cut manual entry — Owlery uses them whenever item-level data is missing. * **Tendering**: review Two Step Tendering and reference visibility before going live with carriers. ## Settings Groups Set the fallback people Owlery emails when there's no more specific contact. Control what information your orders carry. Set the values that prefill your quotes and choose which carriers price them. Control what goes out when you tender, and what carriers can see beforehand. Set on-time grace periods, load creation rules, and shipment IDs. Choose which carriers' exceptions reach your Needs Attention queue. Choose which shipment documents your team can generate, including custom templates. Automate invoice decisions, batch payments, and set carrier payment terms. Show your own written procedures to your team inside the workflow. # SOS Inventory Integration Source: https://help.owlery.ai/shippers/sos-inventory Owlery learns your order and item conventions, then recommends the mapping. Owlery connects to SOS Inventory through OAuth 2.0. We synchronize sales orders, purchase orders, transfers, item records, locations, customers, vendors, units, and packaging relationships into Owlery. The connector is designed for a focused inbound workflow. Owlery can adapt the item field used as your operational SKU without asking you to rewrite existing item records. **Where to find it:** `Settings → Integrations` ## Two parts of the integration Synchronize all three order families and the item master with supporting records. Review SKU-source, display-name, full-sync, exact-refresh, and search behavior. The current SOS Inventory connector is read-only. Owlery documents any requested outbound workflow separately before proposing an extension. ## Getting started An authorized user [connects SOS Inventory to Owlery](/shippers/sos-inventory/connect). The user signs in and approves access; Owlery handles the OAuth 2.0 credentials and tokens. Share representative sales, purchase, or transfer orders and items. Owlery learns your locations, addresses, identifiers, units, and packaging conventions from the data. Owlery presents the recommended SKU source and order mapping. Your team confirms the intended operational result. Owlery validates full and incremental sync behavior, starts synchronization, and monitors the first records. Need help planning your SOS Inventory connection? Email [support@owlery.ai](mailto:support@owlery.ai). # SOS Inventory Configuration Reference Source: https://help.owlery.ai/shippers/sos-inventory/configuration SKU source, display-name, synchronization, exact-refresh, and search behavior. SOS Inventory has a focused configuration surface. Owlery inspects your item records and recommends an override only when the standard mapping does not match your operating model. | Area | Available controls | | ------------------------ | ------------------------------------------------------------------------------------ | | SKU source | Use the standard `sku` field or another available item field | | Display name | When `name` is the SKU, choose the first usable descriptive field as the item label | | Full or incremental sync | Run a complete synchronization or retrieve changed orders | | Exact refresh | Refresh one Owlery order from its SOS source ID | | Search | Search supported fields such as order number, comment, customer PO, or customer name | ## SKU mapping Owlery uses `sku` by default. Some accounts use another item field, such as `name`, as the operational SKU. Owlery can select that field without rewriting existing item records. When `name` becomes the SKU, Owlery chooses a separate display name from the first populated full name, description, purchase description, or original name. The selected source field must be available on the SOS item response. ## Authentication details An authorized user grants Owlery access through SOS Inventory OAuth 2.0. The account needs read permission for Items, units, sales orders, purchase orders, transfers, locations, customers, and vendors. Owlery coordinates token refresh so concurrent requests do not replace the same refresh token. ## Read-only boundary The current connector does not write back to SOS Inventory. If outbound updates are required, Owlery documents the event, target record, fields, and API behavior before proposing an extension. # Connect SOS Inventory to Owlery Source: https://help.owlery.ai/shippers/sos-inventory/connect Authorize your SOS Inventory account while Owlery handles the OAuth 2.0 credentials and tokens. Connecting SOS Inventory is a one-time approval. You do not need to register an application, copy credentials, or manage access tokens. **Where to find it:** `Settings → Integrations` OAuth 2.0 lets you approve Owlery without sharing your SOS Inventory password. SOS Inventory gives Owlery a revocable token that is limited by the approving account's permissions. ## Before You Start You need: * An SOS Inventory account with access to the records Owlery will synchronize * Permission to authorize API access * Your Owlery sign-in The SOS Inventory account should be able to read Items, units, sales orders, purchase orders, transfers, locations, customers, and vendors. ## Connect SOS Inventory In Owlery, go to `Settings → Integrations`. Find **SOS Inventory** and click **Connect**. Owlery sends you to SOS Inventory's secure authorization page. Sign in with the account whose permissions Owlery should use. If your browser blocks the new page, allow pop-ups for Owlery and click **Connect** again. Review and approve the request. SOS Inventory sends the approval code directly to Owlery. You do not need to copy it. SOS Inventory sends you back to Owlery. Confirm that the integration shows **Connected**. ## What Owlery Handles Owlery maintains the registered SOS Inventory application, exchanges the approval for secure tokens, stores the tokens, and refreshes access before it expires. Your team does not need to create a developer account or rotate tokens. SOS Inventory documents the underlying process in its [Authentication](https://developer.sosinventory.com/apidoc/authentication) guide. That guide is for developers; the connection steps above are all you need. ## Troubleshooting Ask your SOS Inventory administrator to confirm that your account can authorize API access, or have the administrator complete the connection. Confirm that the SOS Inventory account can read every required record type. The integration cannot read records that the approving account cannot access. Start again from `Settings → Integrations` and complete the approval in one browser session. If it still fails, send the error message to [support@owlery.ai](mailto:support@owlery.ai). See which SOS Inventory records Owlery synchronizes after authorization. # Reading Data from SOS Inventory Source: https://help.owlery.ai/shippers/sos-inventory/reading-data How Owlery synchronizes SOS orders, items, locations, partners, units, and packaging. Once SOS Inventory is authorized, Owlery retrieves each order family and the item master in pages, then resolves the supporting records needed for freight planning. ## Orders | SOS Inventory record | How Owlery uses it | | -------------------- | ------------------------------------------------------------------ | | Sales Order | Customer shipment from an SOS location to the shipping address | | Purchase Order | Supplier shipment from the vendor to the purchase shipping address | | Transfer | Internal shipment between source and destination SOS locations | Mapped data can include source IDs, order numbers, open or closed status, dates, customers or vendors, facilities, expected ship or delivery dates, customer references, items, descriptions, quantities, line numbers, prices, totals, units, and transfer notes. ## Item master Owlery can synchronize: * SOS item ID and type * SKU, name, and description * Barcode and notes * Source synchronization timestamp when available * Base and alternate units of measure * Packaging conversion relationships When SOS provides a base unit and an alternate case unit with a conversion, Owlery preserves that relationship for shipment planning. ## Supporting records Owlery batches and caches item, location, customer, and vendor lookups during synchronization. This converts SOS Inventory IDs into usable facilities, partners, item details, and packaging without repeatedly calling the same supporting endpoint. ## Synchronization and reliability * **Request pacing** respects the SOS Inventory API throttle with an operational buffer. * **Pagination** uses the supported page size and follows reported totals. * **Incremental overlap** includes one minute before the prior successful boundary. * **Parallel family reads** request sales, purchases, and transfers while a shared limiter controls pacing. * **Batched lookups** group supporting IDs into bounded requests. * **Local caching** avoids duplicate lookups during one sync. * **Refresh locking** prevents concurrent OAuth token rotation. * **Exact refresh** reloads one source order by ID. The current connector is read-only. It does not write shipment, fulfillment, receipt, quote, or status updates to SOS Inventory. # Spot Savings Source: https://help.owlery.ai/shippers/spot-savings How Owlery measures spot savings and how to read the Spot Loads dashboard. **Where to find it:** `Analytics → Metrics Overview → Operations Tab` Spot savings measures how much you saved by tendering below the **midpoint** of the comparable bids you received on a quote. *Midpoint* means the **median bid**: line every comparable bid up from cheapest to most expensive and take the one in the middle. It is not the halfway point between your cheapest and most expensive bid — that figure gets pulled around by a single unusual quote, and Owlery doesn't use it. *Comparable* means bids on the same side of the LTL / non-LTL line as the rate you tendered. See [Which Bids Get Compared](#which-bids-get-compared). ## What Counts as a Spot Load A spot load is one you put out to bid. Loads moved on a [contract rate](/shippers/contract-rates-overview) are excluded, because there was no bidding process and so nothing to compare against. ## Which Bids Get Compared A single quote can come back with bids across more than one mode — that's the point of quoting modes side by side. But an LTL rate and a truckload rate are not two prices for the same thing, and putting them in one field would overstate what your bidding event was worth. So Owlery splits each quote's bids into two groups, **LTL** and **non-LTL**, and measures savings inside the group you tendered from: * Tender an LTL rate, and the midpoint is the midpoint of the **LTL bids only**. * Tender a non-LTL rate, and the midpoint is the midpoint of the **non-LTL bids only**. Bids from the other group are still visible in your bid table and your exports. They just don't set the benchmark. **Within that group, every bid counts toward the midpoint, including the one you tendered** — the midpoint describes the whole comparable field, not the field minus your winner. ### Why the Split Matters Take a quote that drew six bids across both modes: | Carrier | Bid | Group | | --------- | -------------------- | ------- | | Carrier A | **\$950** — tendered | LTL | | Carrier B | \$1,010 | LTL | | Carrier C | \$1,180 | LTL | | Carrier D | \$1,900 | Non-LTL | | Carrier E | \$2,050 | Non-LTL | | Carrier F | \$2,400 | Non-LTL | Thrown into one field, the midpoint lands at \$1,540 and the load reports **\$590** saved. But nothing about your bidding event produced that gap — most of it is the ordinary distance between shipping a partial load LTL and buying a whole truck. You'd be taking credit for choosing a mode. Measured against the LTL bids alone, the midpoint is \$1,010 and the load reports **\$60**. That's the honest number: what running the event was worth once mode is held constant. ## How Spot Savings Is Calculated Spot savings is the **midpoint of the comparable bids you received** minus the **rate you tendered**. With an even number of comparable bids, Owlery averages the two middle bids. ### A Worked Example A quote that received five FTL bids, tendered FTL — so the comparable group is the non-LTL bids: | Carrier | Bid | | --------- | ---------------------- | | Carrier A | **\$950** — tendered | | Carrier B | \$955 | | Carrier C | **\$1,100** — midpoint | | Carrier D | \$1,200 | | Carrier E | \$2,400 | The middle bid of the five is \$1,100. You tendered \$950. Spot savings on this load is **\$150**, or about 13.6% below the midpoint of the comparable market you saw. ### Why the Midpoint The midpoint estimates what the load would have cost without a competitive bidding process — an ordinary price from a market that was never under pressure to sharpen its pencil. Owlery uses it in preference to the second-cheapest bid, the average, or the most expensive bid, each of which either answers a different question or moves too easily on a single outlier. The full reasoning, with a worked comparison of all four benchmarks, is on [Why Owlery Uses the Midpoint](/shippers/spot-savings-methodology). Spot savings is a benchmark, not an accounting figure. It measures the value of running a competitive event against the comparable market you saw on that quote. It isn't money that appears anywhere in your ledger, and it isn't a comparison against a budget, a contract rate, a market index, or what the same load would have cost in another mode. ## The Summary Tiles | Tile | What it shows | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Loads** | How many loads fall inside your date range. | | **Avg Bids per Spot Load** | How many carriers responded to a typical quote. | | **Total Spot Savings** | Spot savings added up across every spot load in your date range. | | **Avg Spot Savings per Load** | Total spot savings divided by the number of spot loads. | | **Avg Spot Savings (25th percentile)** | The same average, benchmarked against the 25th-percentile comparable bid instead of the midpoint — a deliberately conservative view. | | **Avg Spot Savings (75th percentile)** | The same average, benchmarked against the 75th-percentile comparable bid — a deliberately generous one. | **Avg Bids per Spot Load** is the one to watch alongside the savings figures. Spot savings depends entirely on carriers competing for your freight — more bids means a wider spread and a more meaningful midpoint. When this number falls, savings usually fall with it. **Avg Bids per Spot Load** counts every bid on the quote, both groups. The savings figures use only the comparable group. On a quote that drew bids across both modes, the bid count will be higher than the number of bids that actually set the benchmark. ### The Percentile Tiles These two don't describe how savings varied from load to load. They re-run the whole calculation against a different benchmark: instead of the middle bid, take the bid a quarter of the way up the comparable field — or three quarters of the way up — and average across your loads exactly as before. The LTL / non-LTL split applies here too. What you get is a range around the headline figure. The 25th-percentile number is what your savings look like under a stingy assumption about what you'd otherwise have paid; the 75th-percentile number is what they look like under a generous one. The midpoint sits between them by design. Reading all three tells you how much the answer depends on that assumption. Sitting close together means the benchmark choice barely matters and the headline number is on solid ground. Spread far apart means your bid fields are wide, and the figure leans more heavily on that middle assumption than it does on a tight day. ## The Charts ### Bids per Spot Load A stacked bar per week showing what share of that week's loads drew each number of bids. Each color is a bid count, so a bar that is mostly dark green means most loads that week attracted seven or more carriers. Watch for red, which is a single bid. A load with only one bid cannot produce savings — see [When Savings Show as \$0](#when-savings-show-as-0). ### Spot Savings Two series drawn on one chart: * **Total Spot Savings** (green bars): the dollars saved that week. This moves with load volume, so a short bar can mean a quiet week rather than a bad one. * **Average Spot Savings** (blue line): the dollars saved on a typical load. This is the better line to trend, because volume doesn't distort it. The first and last points on both weekly charts almost always cover **partial weeks** clipped by the edge of your date range. A dip at either end is usually your date filter, not a real change. ## The Load Tables Under the charts are two tables. They cover the same loads and differ in what a single row means. | Table | One row is | Use it for | | ---------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Bids per Spot Load** | one spot load | Load-level figures — cost, bid count, and the spot savings Owlery calculated. | | **Spot Loads with all Bids** | one bid | Seeing the field behind a load — carrier name and bid amount for every bid received, across both groups. Scroll right for the full set of columns, or download it. | Either one exports. Click the **⋯** at the top right of the table and pick CSV or Excel. When you export **Spot Loads with all Bids**, the load-level columns repeat on every row belonging to the same load. A load that drew 17 bids appears as 17 rows, each carrying that same load's cost and savings. Summing that column would count the same savings 17 times over. Use **Bids per Spot Load** for anything you plan to total. ## Measure It Your Own Way The midpoint of the comparable field is what Owlery reports because it's the benchmark we'd defend — see [Why Owlery Uses the Midpoint](/shippers/spot-savings-methodology). It isn't the only defensible one, and it doesn't know your lanes the way you do. So the bids are yours to take. The export carries the full field, both groups, so you can measure against the second-cheapest bid, trim the top and bottom off each field, weight by lane or by volume, cut the modes more finely than LTL versus everything else, or set the whole thing against your contract rates. If you land somewhere different and it holds up on your freight, we'd like to hear about it. ## When Savings Show as \$0 The ordinary reason a load shows no savings is that **only one comparable carrier bid**. With a single bid in the group you tendered from, that bid is also the midpoint, so the midpoint and the rate you tendered are the same number. A week where every load drew one comparable bid will show \$0 total savings. This can happen on a quote that looks busy. Six bids where five were non-LTL and you tendered the only LTL rate is a one-bid comparison, and it will report \$0. That doesn't mean anything is broken, but it is worth chasing: it points to a carrier coverage gap in that mode on that lane rather than a pricing problem. ## Common Questions Check the **Average Spot Savings** line before worrying. Total savings moves with how many loads you shipped, so a quiet week produces a short bar even when every load performed well. It means you tendered below the middle of the comparable bids you received. Whether a cheaper rate existed somewhere in the wider market is a different question, and this dashboard can't answer it. Because it's a different kind of saving. Spot savings sizes what competitive bidding was worth with mode held constant; mode conversion is a load planning decision, and folding the two together would make both harder to read. The truckload bids are in your export if you want to size the conversion separately. Check how the field split. If all but one of those bids sat on the other side of the LTL / non-LTL line, only one bid was comparable, and a single comparable bid is its own midpoint. # Why Owlery Uses the Midpoint Source: https://help.owlery.ai/shippers/spot-savings-methodology Why spot savings is benchmarked against the median of all bids rather than the average or second-cheapest. **Where to find it:** `Analytics → Metrics Overview → Operations Tab` Spot savings compares the rate you tendered against the **midpoint** — the median — of the comparable bids you received on that quote. For how to read the dashboard, see [Spot Savings](/shippers/spot-savings). This page covers why the midpoint is the benchmark, and why the comparison set is drawn where it is. ## The Question the Metric Answers Spot savings answers one question: **what would this load have cost without a competitive bidding process?** Without one, you'd have called a broker or two and taken what came back. It's fair to object that you'd still have taken the cheaper of those two calls, which would put you below the midpoint of five bids rather than at it. But that objection assumes those brokers would have quoted you the same numbers either way, and they wouldn't have. A carrier bidding into an open event knows it is being compared. A carrier quoting a shipper who rang them directly knows it isn't. Running the event doesn't just show you more of the market — it changes the prices the market shows you. So the right comparison isn't the cheapest quote from a smaller sample. It's an ordinary price from a market that was never under pressure to sharpen its pencil, and the midpoint is Owlery's estimate of that price. ## Comparing Like With Like Note the word *comparable*. Before any benchmark gets picked, the field has to be drawn, and Owlery draws it inside a single mode class: **LTL bids are compared against LTL bids, non-LTL against non-LTL.** Whichever group you tendered from is the group the midpoint comes from. The reason is that mixing them measures the wrong thing. The gap between an LTL rate on a partial load and a truckload rate on the same lane is mostly the gap between two different products — you are buying part of a trailer in one case and all of it in the other. Put both in one field and the midpoint drifts up into truckload territory, and every LTL tender starts reporting savings it did nothing to earn. The metric would be crediting your bidding event for a decision made in load planning. The [worked mixed-mode example](/shippers/spot-savings#why-the-split-matters) on the dashboard page puts numbers on it: the same load reports \$590 saved on a combined field and \$60 on an LTL-only one. The \$590 is not a measure of competitive pressure. It's a measure of trailer size. This cuts against the number, which is the point. Where a choice about scope could plausibly go either way, Owlery takes the one that reports less, so that the figure survives someone checking it. Mode conversion savings are real — moving freight off truckload and onto LTL where it fits is worth money. They're just a different metric, sized in load planning, and keeping them out of spot savings is what lets either number mean something on its own. **A consequence worth knowing:** on a quote where the split leaves only one comparable bid, savings report \$0 even if the quote drew a healthy number of bids overall. That is the scope working as intended, not a gap in coverage on the whole quote — though it usually does point to thin coverage in that mode on that lane. ## The Benchmarks Considered Four benchmarks were considered. Applied to the five comparable bids in [A Worked Example](/shippers/spot-savings#a-worked-example) — Carriers A through E bidding \$950, \$955, \$1,100, \$1,200, and \$2,400, with Carrier A's \$950 tendered and \$1,100 the midpoint: | Benchmark | Savings it would report | How it holds up | | ----------------------------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Second-cheapest bid (\$955) | \$5 | Answers a different question, and behaves backwards as a headline number — see [On the Second-Cheapest Bid](#on-the-second-cheapest-bid). | | Most expensive bid (\$2,400) | \$1,450 | Assumes you'd otherwise have picked the worst rate on the board, which nobody would defend. | | Average of comparable bids (\$1,321) | \$371 | A single runaway bid drags it. Drop the \$2,400 quote and reported savings fall substantially. | | **Midpoint of comparable bids (\$1,100)** | **\$150** | Assumes neither the best nor the worst case, and an outlier bid moves it far less than it moves the average. | ## On the Second-Cheapest Bid Measuring against the second-cheapest bid is a reasonable answer to a *different* question: what would this load have cost if my best carrier hadn't shown up? That's worth knowing, and it's a fair way to size how exposed a lane is to a single carrier. It just isn't a measure of what competitive bidding is worth to you. It also behaves backwards as a headline number. In that example, Carrier A and Carrier B came in at \$950 and \$955, while the rest of the field sat at \$1,100 and above. Against the second-cheapest bid, that load reports \$5 saved. Against the midpoint, it reports \$150. The \$5 figure is small precisely because you got two of your carriers to fight hard, which means the measure shows the least impact when your event worked best. It also only ever looks at the top two bids, when what you built was competitive pressure across the whole field. That field is what is worth measuring against. **It also depends too much on who happened to show up.** Suppose Carrier A sits that event out — truck already booked, dispatcher missed the email, nothing to do with your lane. The other four bids come in unchanged, and you tender Carrier B at \$955. | On this load | Carrier A bids | Carrier A sits out | | ----------------------- | -------------- | ------------------ | | What you paid | \$950 | \$955 | | Second-cheapest reports | \$5 | \$145 | | Midpoint reports | \$150 | \$195 | You paid five dollars more, and the second-cheapest measure rewards you with twenty-nine times the savings. Nothing about the lane changed; one carrier didn't answer the phone. That's the deeper problem. Second-cheapest rests on a single bid, and *which* bid that is depends entirely on who turned up. Lose one carrier and the benchmark relocates. The midpoint rests on the shape of the whole comparable field, so the same missing carrier nudges it instead of moving it. It does rise — from \$1,100 to \$1,150, lifting reported savings by about 30% — because with the cheap end of the field gone, the market you'd have faced without an event genuinely was more expensive. That's a real shift, sized to a real change. The 29x jump is not. This is the ordinary reason to reach for a median instead of a single ranked bid: medians are hard to push around. A benchmark should move when your market moves, and sit still when it doesn't. ## Why This Number Is Almost Always Positive Worth saying plainly: if two or more comparable carriers bid and you tender the cheapest of them, you are below the midpoint by construction, so spot savings will be positive nearly every time. That is the expected result, not a thumb on the scale. Running a competitive event almost always beats not running one, and the metric is sizing *how much* that was worth on a given lane rather than testing *whether* it worked at all. The number that can genuinely go against you is [**Avg Bids per Spot Load**](/shippers/spot-savings#the-summary-tiles) — read the two together. # Team Playbook Settings Source: https://help.owlery.ai/shippers/team-playbooks Turn on private playbooks so your team sees your customer-specific rules inside the workflow. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Team Playbooks` A playbook is your own written procedure for handling something, usually a customer with particular requirements. For example: "Acme won't accept deliveries before 10am and needs appointments booked 24 hours ahead." Owlery shows playbooks to your team inside the relevant workflow, at the point they matter, rather than in a document nobody can find. Your playbooks are private to your organization. ## Enable Team Playbooks **Value:** On / Off **What it does:** Shows the **Playbooks** tab, where your team can read and manage playbooks. **When you'd turn it on:** When you have customer-specific rules your team keeps getting wrong, or keeps having to ask about. Those questions are the signal that the knowledge should be written down where the work happens. The **Playbooks** tab only appears once you have at least one playbook. Turning this setting on isn't enough on its own — create a playbook and the tab appears. Playbooks are written and edited on the **Playbooks** tab. This setting only controls whether that tab is visible. # Tender Release Documents Source: https://help.owlery.ai/shippers/tender-configuration Configure which documents Owlery generates and emails to carriers and facilities the moment you tender a quote. **Where to find it:** `Quotes → open any quote` When you tender a quote in Owlery, you can automatically generate and send your shipment documents — all in one step. This page covers where to find the settings, what each option does, and how to review everything before you confirm. Which documents are available here depends on what's turned on in [Document Settings](/shippers/documents): the three standard documents, plus any custom templates on your account. ## Where the settings live Image Open any rate quote from the **Quotes** page. Next to the rate response table you'll see the **Configuration** card. It shows a summary of what will be sent on tender, and a **Configure** button to adjust the settings. Your configuration is saved to your organization and remembered across all future quotes until you change it. ## What each setting does Click **Configure** on the Sending Configuration card to open the settings table. ### Bill of Lading (BOL) Generates and emails a Bill of Lading at tender time. * **Carrier**: toggle on to email the BOL to the carrier assigned to the load. * **Facilities**: check the stops that should receive the BOL. If every stop is checked, the row switches to **All facilities**. * **CC**: toggle on to CC the order owner on the BOL email. ### Packing list Generates and emails a packing list at tender time. *Sent to facilities only.* * **Facilities**: the packing list is sent to the first pickup facility on the quote. ### Shipping label Generates and emails a shipping label at tender time. *Sent to facilities only.* * **Facilities**: the shipping label is sent to the first pickup facility on the quote. The Shipping Label option requires a shipping label template on your account. If you don't see it, contact [support@owlery.ai](mailto:support@owlery.ai). ### Custom document templates Any custom template you've turned on in [Document Settings](/shippers/documents) gets its own row here, alongside the standard documents. * **Carrier**: toggle on to email the document to the carrier. * **Facilities**: check the stops that should receive it. A template's row appears only when the template applies to the shipment. The Canada customs invoice, for example, shows up only on cross-border Canada moves. ### Send order to facility When toggled on, Owlery sends the related purchase order(s) to the pickup and dropoff facilities via their connected integrations. Orders are matched by reference number. ### Rate confirmation email When toggled on, the carrier or broker receives a rate confirmation email at tender. This is the standard tender notification — leave this on unless you handle ratecons outside Owlery. ## Reviewing before you tender You get three checkpoints so nothing goes out unless you've seen it. ### 1. The summary card The **Sending Configuration** card on the quote shows exactly what will happen at a glance: * Which documents will be sent * To whom: carrier, facilities, or both * Warnings if any selected facility is missing email contacts ### 2. The Configure dialog Click **Configure** to open the full settings table. A live **Summary** panel at the bottom updates as you toggle options, so you always know exactly what will be sent. Click **Save** to apply. ### 3. The confirmation steps When you click the tender button, Owlery walks you through a step-by-step confirmation flow for every document you've configured. You preview each document before it's sent: * **Check BOL**: review the generated BOL and make any last adjustments. * **Check Packing List**: review the packing list before it's emailed. * **Check Shipping Label**: review the shipping label before it's emailed. * **Quote Write Back**: review and confirm any price write-back to your ERP. Custom templates get their own check step too, named after the document. After you confirm each step, the tender is submitted and all documents are sent automatically. ## FAQ Yes. Your configuration is saved at the organization level and applies to all future tenders unless you change it. The summary card and confirmation steps show a warning. The document is still generated, but that facility won't receive the email. Add facility contacts under **Facilities → Contacts** to resolve this. Yes. If your team uses the Routing Guide with Direct Tender, each lane can have its own document-sending configuration. Contact [support@owlery.ai](mailto:support@owlery.ai) to learn more. The tender itself is not affected. The failure is logged and the Owlery team is alerted automatically. Only documents turned on in [Document Settings](/shippers/documents) appear here, and custom templates additionally need to apply to the shipment. Custom templates are built by Owlery on request — contact [support@owlery.ai](mailto:support@owlery.ai) to get one set up. # Tendering Settings Source: https://help.owlery.ai/shippers/tendering Control what goes out when you tender a shipment, who gets told, and what carriers can see. If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected. **Where to find it:** `Dashboard → Shipper Settings → Tendering` Tendering is the moment you stop shopping and start booking: you've picked a price, and now you formally offer the shipment to that carrier. These settings control what goes out with that offer, who gets told, and what carriers can see before they commit. ## Tender Defaults **What it does:** Sets which documents are sent when a shipment is tendered, and who receives them. The editor is a grid. Each row is a document, and the columns are the possible recipients: | Column | Meaning | | -------------- | --------------------------------------------------------------------------- | | **Carrier** | Whether the document is sent to the carrier hauling the load | | **Facilities** | Which stops get it: **All**, **Pickup** only, **Dropoff** only, or **None** | | **CC** | Whether the order owner is copied in | The documents available are the Bill of Lading, packing list, shipping label, the order itself, and the rate confirmation, plus any custom templates you've turned on in [Document Settings](/shippers/documents). Where a column doesn't apply to a document, it reads *Not applicable*. **When you'd change it:** Set this up once to match how your operation communicates. The usual pattern is BOL and rate confirmation to the carrier, BOL and packing list to the pickup facility. These are your organization-wide defaults. Where a route has its own document settings, the route's settings win and saving here won't change them. To check what will be sent on a specific quote and preview each document before it goes out, see [Tender Configuration](/shippers/tender-configuration). ## Two-Step Tendering **Value:** On / Off **What it does:** Adds a confirmation step before a tender is final, rather than the tender being binding the moment it's sent. **When you'd turn it on:** Normally used with direct LTL carrier relationships, where the carrier's process expects a confirmation exchange rather than a single instruction. For what the extra step looks like in practice, see [Two Step Tendering](/shippers/two-step-tendering). ## Tender Acceptance Emails **Value:** On / Off **What it does:** Emails the teammate who tendered the shipment when the carrier accepts it. **When you'd turn it on:** If your team needs to know a booking is confirmed without watching the screen. **When to leave it off:** If your team lives in Owlery all day and the extra email is noise. ## Carrier Chooses Mode **Value:** On / Off **What it does:** On a direct tender, lets the carrier decide the final mode — LTL or full truckload. **When you'd turn it on:** If you have carriers who can move freight either way and are better placed than you to decide which is more efficient. It can produce better pricing and service; the trade-off is you give up control of that choice. ## Carrier Account Manager Notifications **Value:** On / Off **What it does:** As well as your usual contacts, emails the carrier's default account managers about quoting, tendering, and load updates. **When you'd turn it on:** If your carriers' account managers want visibility of your shipments. It helps to have someone at the carrier who can chase an issue for you. ## Pre-Tender Reference Visibility **Value:** On / Off **What it does:** Controls who can see your reference numbers — PO numbers, order numbers, and similar — *before* a shipment is tendered. * **Off** (the default): only a carrier you've actually tendered to can see them. * **On**: every carrier you're quoting with can see them, even ones you don't book. **When you'd turn it on:** If carriers need your reference numbers to quote accurately, for instance to match against a customer's receiving appointment system. **When to leave it off:** If your reference numbers are commercially sensitive. Leaving it off means carriers only see them once they've won the business. # Two Step Tendering Source: https://help.owlery.ai/shippers/two-step-tendering Tender an order with Two Step Tendering enabled: review your details, requote if needed, and submit the final tender. This guide walks you through tendering an order (when Two Step Tendering is enabled in your shipper settings) — from reviewing your details to submitting the final tender. ## 1. Start the tender * Find the original quote. * Click **Proceed to Tender**. Before anything is submitted, you'll have a chance to review and confirm your details. Image ## 2. Review changes to your order The system automatically checks whether your order has changed since the original quote. You then have two options: * **Tender the original quote**: Submit using the quote exactly as it was. * **Requote from the latest order details**: Recalculate the shipment using your most current order information, such as updated dates or reference numbers. Image If you choose to requote, the system will automatically: * Recalculate the shipment from the latest order information * Include the BOL, if one is available * Update all dates to the latest ## 3. Make any final adjustments Even after requoting, you have full flexibility to customize the shipment. You can: * Update the quantity * Add additional reference numbers * Change stop dates * Add instructions or contact information for a specific shipment ## 4. Confirm and tender Once you confirm your details, the system attempts the tender. What happens next depends on your rate type: * **FTL rates** (from contracts or carrier portal): The tender uses the rate the carrier previously provided. * **LTL rates** (quoted through the API): The tender goes through automatically. If the rate has changed, you'll be asked to confirm whether the new rate is acceptable before continuing. ## 5. Complete the tender workflow From here, the standard tender workflow continues, and any required tender configuration steps will appear. Some configurations may include additional prompts, such as recording the quote again, depending on your setup. # Shipper Guide Source: https://help.owlery.ai/shippers/welcome Everything shippers need to set up Owlery and move freight — from settings and integrations to orders, loads, and invoices. Configure your shipper settings, build your item master, load contract rates, and start shipping. Connect ERPs, brokers, 3PLs, and direct carriers so data moves on its own. ## Platform Create and manage shipping orders. Track shipments and create BOLs. Manage carrier invoicing and billing. ## Setup & Configuration Set your default origin, packaging, and quoting preferences. Add SKUs with dimensions and weights to drive pallet counts, BOL lines, and load building. Upload pre-negotiated lane prices so they surface automatically when you quote. Ask your carriers to bid on a set of lanes, then award the bids you want as contract rates. Connect ERPs, brokers, 3PLs, and direct carriers. *** Stuck on something? Email [support@owlery.ai](mailto:support@owlery.ai) # Signing In to Owlery Source: https://help.owlery.ai/signing-in How to log in with your work email using Google, Microsoft, or a magic link. Owlery uses Single Sign-On (SSO), so there's no separate password to create or remember. Sign in with your work email through Google or Microsoft, and Owlery matches you to your company based on your email domain. You must use your **work email**. Personal email accounts (Gmail, Outlook.com, etc.) won't work. Image ## Sign in with Google or Microsoft Open Owlery in your browser. You'll land on the sign-in screen. Click **Continue with Microsoft** or **Continue with Google** — whichever one your company uses for work email. Sign in with your work email credentials through your provider's standard login screen. If you're already signed in to Google or Microsoft in your browser, this may happen automatically. That's it — you're in. Owlery never sees or stores your password; your identity provider handles all of that. ## If your IT team manages access If your organization controls which third-party apps employees can use, your IT team may need to approve Owlery before you can sign in. Reach out to your IT team to request access. *What your IT team will need to do:* * Mark Owlery as an approved application in your identity provider (Google Workspace, Microsoft Entra ID, etc.) * Allow the appropriate users or groups to access Owlery * Optionally, manage ongoing access through groups Your IT team maintains authentication entirely on their side — Owlery does not store or manage customer user passwords. ## Use a magic link instead If your company doesn't use Google or Microsoft, you can sign in with a secure email link (referred to as a "magic link"). On the sign-in screen, click **Get a secure sign-in link by email**. Type your work email address and submit. Open the sign-in email from Owlery and click the link. It'll sign you straight in. Screenshot 2026 07 14 At 1 33 04 PM If your company uses an email security tool like Proofpoint, Mimecast, or Barracuda, links from Owlery — including your sign-in link and file downloads (invoices, reports, PODs) — may be rewritten to route through the security tool. That can break the sign-in link and cause downloads to show **Download Blocked** or **Unable to process file at this time**. You have two options if this happens – either one works: * **Copy the sign-in link and paste it into your browser** instead of clicking it. This is the fastest fix and works right away. * **Ask your IT team to allowlist** `owlery.ai `**(and** `*.owlery.ai`**)** in your email security tool. This is the permanent fix, but IT teams are often slow to act — most people should use the copy-paste sign in link option in the meantime. ## What Owlery stores about you When you sign in, Owlery only stores three things: your **name**, your **email address**, and an internal system ID. That's it — no passwords, no extra profile data. ## Troubleshooting Owlery runs on enterprise-grade infrastructure with encryption at rest and in transit. We do not store user information beyond basic account creation *(see [What Owlery Stores about you](#what-owlery-stores-about-you) above)*. For a live list of our security & compliance controls, subprocessors, and common FAQs, your IT team can visit our [Trust & Security Center](https://trust.owlery.ai/). Your IT team may need to whitelist Owlery in your organization's Google or Microsoft admin settings. See [*If your IT team manages access*](#if-your-it-team-manages-access) above. Check with them first — if that doesn't fix it, email [support@owlery.ai](mailto:support@owlery.ai) with your company name and the error you're seeing. Owlery matches you to your organization by your email domain. If you're signed in with your correct work email and still don't see what you expect, check with a teammate - they probably just need to add you to the right team. See [Invite Team Members](/inviting-team-members) for how they do that, and what to do if your email is on a different domain than the rest of the organization. This almost always means your company's email security tool (Proofpoint, Mimecast, Barracuda, etc.) is intercepting the download and blocking it. **The quickest fix:** copy the sign-in link from your email and paste it into your browser instead of clicking it, then try the download again. **The permanent fix:** ask your IT team to allowlist `owlery.ai` in your email security tool. This can take a while, so use the copy-paste option in the meantime. **Why this happens:** Owlery generates your files directly in your browser and hands them to you through a private, one-time link that only exists inside your current browser tab. Nothing is ever posted to a public URL, which keeps your data and reports from being shared, cached, or scraped. When a security tool tries to re-open that link from its own scanner, the file isn't there — so the download fails. # Switch to Dark Mode Source: https://help.owlery.ai/switch-to-dark-mode Choose between light mode, dark mode, or let Owlery follow your system setting. Owlery supports light mode, dark mode, and a system option that follows whatever your device is already set to. System is the default, so if your OS is set to dark, Owlery already is too. ## Change your appearance setting Click your **avatar** in the top-right corner of the dashboard. Under **Appearance**, choose one of three options: * **System**: matches your operating system or browser preference. This is the default. * **Light**: always light, regardless of your system setting. * **Dark**: always dark, regardless of your system setting. Your choice takes effect immediately. This setting is saved to your browser, not your account. If you switch browsers or devices, you'll need to set it again. # Welcome Source: https://help.owlery.ai/welcome Start here — find the guide for your role, whether you ship, haul, or run the dock. Owlery is the AI-powered TMS and Logistics Platform built for modern supply chains. We know that *No One Ships Alone*. This guide has everything you need to get set up and moving freight, no matter which side of the shipment you're on. How to log in and access Owlery Quote, book, and track shipments. Manage orders, build loads, and handle carrier invoicing. Accept tenders, update shipment statuses, and manage freight you're hauling through Owlery. Set up your docks, hours, and appointment rules to manage your inbound and outbound freight. Book and manage your pickup and delivery appointments at facilities that use Owlery.