Understanding billing

As part of the Google Maps Platform Last Mile Fleet Solution (LMFS) terms, a billable transaction occurs with the successful completion of the tasks associated with a shipment.

The Task object is a fundamental object type that plays a key role in tracking and reporting billable transactions in the LMFS Deliveries API. Our terms require you to model the driver's tasks correctly and record the TaskOutcome appropriately. This ensures that all billable transactions are recorded correctly. For contracted customers, see the applicable Reporting Requirements for your product:

What is a billable task?

A billable task is any task that successfully completes a shipment: the transport of one or more items from a unique shipper to a unique recipient. Failed shipment tasks are not billable.

The following table provides a few real-world scenarios for billable and non-billable tasks.

Scenario Billable?
A driver attempted to deliver a package and the attempt was successful. For example, the recipient received it directly, or the driver left the package with a neighbor. Yes
A driver delivered a package outside the intended time window stated for that package. Yes
A driver reported a shipment as successful, but the recipient later disputed the receipt of the shipment. Yes
A driver attempted to deliver a package but the attempt failed. For example, the recipient was not home for a required signature, or the address was wrong. No
A driver takes a scheduled break or stop. No

How does billing happen inside Deliveries API?

A task is billed under the following conditions:

  • The Task has a type set to delivery. Pickup tasks do not trigger billing, and Scheduled breaks or stops do not qualify. Every billable transaction must have a delivery task associated with it. First mile pickups delivered to a depot can have the pickup task modeled at the pickup location and the delivery task modeled at the depot.

  • The TaskOutcome has the value SUCCEEDED.

The Last Mile Fleet Solution Deliveries API creates a billable event the first time a TaskOutcome is updated with a value of SUCCEEDED. When this happens, it increments the billing metric for that SKU. Any subsequent updates to that task do not impact this billing metric, which cannot be incremented or decremented after the outcome is first set.

How should you model your tasks?

This section provides basic recommendations to help you check that you've correctly set your tasks per our terms and conditions.

  • Set the right fields for shipments tasks. Set the task type to delivery, assign a unique task ID, and specify the correct location for the completion of each task. Ensure every shipment has a delivery task.
  • Create separate tasks for each shipper-recipient combination. For example, use two tasks for a single recipient from multiple shippers. Or, for a single delivery location where multiple packages will be delivered to multiple recipients, create multiple tasks.
  • Define non-shipment tasks correctly. For scheduled stops, set the task Type to SCHEDULED_STOP. For driver breaks, set the Type to UNAVAILABLE.
  • Set the TaskOutcome field appropriately. When the task completes, make sure your implementation sets the TaskOutcome to either SUCCEEDED or FAILED. Merely updating a completed task to a CLOSED state does not comply with our terms. You can set the task outcome using the Driver SDK, gRPC, or REST.

For more information, see the following Fleet Engine User Guide topics: