News
Your Three Bubbles Did Not Cost You Three Messages, Your Recipient List Did
Your LINE message count is one multiplication and nothing else: how many times you pressed send, times how many people were on the receiving end. Bubbles are free. Push a single broadcast carrying three bubbles to 5,000 friends from your LINE Official Account and the platform records 5,000 against your quota, so the figure 15,000 never appears on any screen you will ever look at. This is the arithmetic behind every invoice this channel will send you.
LINE’s developer team published a clarifier about it in Japanese on 28 May 2026, under the title 今さら聞けない！Messaging APIの通数カウント方法, which reads roughly as the message counting method you are now too embarrassed to ask about. Nobody writes that article for fun. Enough operators had budgeted by counting bubbles that the platform decided a dedicated explainer was worth publishing.
Table of Contents
The formula, written out in full
LINE Yahoo for Business states the rule on its own plan page as 「メッセージを送った回数」×「送った友だちの数」. The number of times you sent a message, multiplied by the number of friends you sent it to. Both halves of that matter, and neither half has anything to do with what was inside the message.
A broadcast is one send. It becomes 5,000 counted messages because 5,000 people were on the list, and the same broadcast becomes 12 counted messages if 12 people were on the list. Adding an image, a coupon block and a second paragraph to that broadcast changes the payload and changes nothing about the charge. The meter does not read your content.
Worked examples you can check against your own report
| What you send | Sends | Recipients reached | Counted messages |
|---|---|---|---|
| One broadcast, 1 bubble, to 5,000 friends | 1 | 5,000 | 5,000 |
| One broadcast, 3 bubbles, to 5,000 friends | 1 | 5,000 | 5,000 |
| One API request, 5 message objects, to 5 users | 1 | 5 | 5 |
| Four broadcasts in a month, 3 bubbles each, to 150 friends | 4 | 150 | 600 |
| One broadcast to 5,000 friends, 800 of whom blocked you | 1 | 4,200 | 4,200 |
| Ten Messaging API replies to ten incoming questions | 10 | 10 | 0 |
That last row is not a typo, and it is worth more to a large account than anything else on this page. Replies are excluded from billing entirely.
The bubble ceiling changes depending on which door you came through
Here is a difference that has almost no English documentation anywhere. The limit on how much you can pack into one send is set by the interface, and the two interfaces disagree.
In LINE Official Account Manager, the web console most marketing teams actually work in, one message send carries a maximum of three bubbles. LINE Yahoo for Business writes it as 最大3吹き出しまで. That is a hard stop in that console.
Through the Messaging API the limit is five. The official documentation is unambiguous about it: in a single request you can send up to five message objects. Push, multicast, broadcast and narrowcast requests all share that ceiling, and a reply may carry five as well.
Both routes cost the same, because both are one send per recipient. So an operator who designs every campaign around three blocks, because three is what the console offers, is leaving two of the five available slots empty on every API send. That is 40 percent of a payload they have already paid for, going unused.
The saving everybody reaches for first, which saves nothing
Write shorter. Cut the second bubble, drop the image, lose the coupon card and get the whole message into one tidy line of text, then watch the monthly bill come down.
You were expecting me to say all that, right? It saves you nothing at all. A one bubble broadcast to 5,000 friends and a three bubble broadcast to 5,000 friends produce identical entries on your invoice, so the shorter version simply does less work for exactly the same money. Trimming copy is a conversion decision. It has never been a cost decision on this platform.
Two things move your bill. The size of the list you send to, and the number of times you press send. Everything else in the composer is free.
Which sends are billed and which are not
| Message type | Counts against your quota |
|---|---|
| Broadcast, 一斉配信 | Yes |
| Segmented or narrowcast delivery, 絞り込み配信 | Yes |
| Step delivery, ステップ配信 | Yes |
| Messaging API push message | Yes |
| Messaging API multicast message | Yes |
| Messaging API broadcast and narrowcast | Yes |
| Messaging API reply message | No |
| One to one chat with a customer | No |
| Auto reply, 応答メッセージ | No |
| Greeting message on add, あいさつメッセージ | No |
| Rich menu, リッチメニュー | No |
| LINE VOOM post | No |
Read that table with the push and reply split in mind. It is the biggest lever anyone running automation has. A reply, sent because a user did something first, carries no charge at all. A push, sent because your system decided to speak first, carries the full charge for every recipient. Redesigning a flow so it answers instead of initiating can take a five figure line item down to zero, and the customer experience often improves as a side effect, since the message now arrives when somebody actually asked for it.
Greeting messages deserve a note too. The message a new friend receives on adding your account is free, forever, at any volume. If you are paying for a welcome broadcast to recent additions, you are paying for something the platform already gives away.
Blocked friends never reach the meter
Undeliverable sends are excluded. LINE’s own wording: if you send a message to a user who blocked your LINE Official Account, or to a user ID that does not exist, the message is not counted.
The practical effect is that quota consumption will never equal your friend count. Some share of that headline number has blocked you, and some share is unreachable for other reasons, so forecasting from friend count will always overstate your spend. Forecast from target reach instead. Target reach is the friend total with blocked and unclassified users stripped out, and it is much closer to the population that will actually cost you money.
There is an uncomfortable second reading of this. A neglected list is cheaper than it looks, because you are not billed for the people who left. You are also not reaching them, while they continue to inflate the friend number somebody is reporting upward every quarter.
Putting a real month through the formula
Take a Japanese account on the Standard plan, ¥15,000 a month excluding tax, which includes 30,000 messages. The list holds 8,000 friends and target reach sits at 6,800. Four broadcasts go out during the month.
Four sends multiplied by 6,800 reachable recipients gives 27,200 counted messages. That fits inside the allowance, so the month costs ¥15,000 plus tax and not a yen more, no matter how many bubbles went into each of those four broadcasts. Now add a fifth broadcast. You land on 34,000 counted messages, which puts 4,000 beyond the allowance at up to ¥3 each in Japan, so roughly ¥12,000 of additional spend.
That extra spend only happens if you raised your additional message ceiling in advance. Leave it alone and the fifth broadcast does not cost ¥12,000. It does not go out at all.
What to check before your next campaign
- Count sends for the month rather than bubbles, then multiply by target reach rather than friend count.
- Move anything you can from the console to the Messaging API if payload is tight, since five objects per request beats three bubbles per send at the same price.
- Audit your automated flows and mark each one as a push or a reply, because only the pushes are billed.
- Confirm your greeting message and auto replies are doing the work you might otherwise pay a broadcast to do.
- Check your additional message ceiling before the month you need it, since the same arithmetic that predicts your bill also predicts the day your sending stops.
The formula is small enough to keep in your head, which is the whole point. Sends times recipients. Every planning argument about message length, image count and card design is a marketing argument from here on, and none of it belongs in the budget conversation.
